On Thu, Apr 17, 2008 at 11:48:41AM -0400, Tom Lane wrote:
Martijn van Oosterhout <firstname.lastname@example.org> writes:
Is this so? This happened to me the other day (hence the question about
having COPY note failure earlier) because the disk filled up. I was
confused because du showed nothing. Eventually I did an lsof and found
the postgres backend had a large number of open file handles to deleted
files (each one gigabyte).
The backend, or the bgwriter? Please be specific.
I beleive the backend, because I was using lsof -p <pid> using the pid
copied from ps. But I can't be 100%.
8.3 and HEAD should ftruncate() the first segment of a relation but I
think they just unlink the rest. Is it sane to think of ftruncate then
unlink on the non-first segments, to alleviate the disk-space issue when
someone else is holding the file open?
It's possible. OTOH, if the copy error had been return in the
PQputline() the driving program (which has several COPYs running at
once) would have aborted and the data would have been reclaimed
immediately. As it is it kept going for an hour before noticing and
then dying (and cleaning everything up).
The one ftruncate does explain why there was some free space, so that
part is appreciated.
Have a nice day,
Martijn van Oosterhout <email@example.com> http://svana.org/kleptog/
Please line up in a tree and maintain the heap invariant while
boarding. Thank you for flying nlogn airlines.