Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory |
Дата | |
Msg-id | 20559.1208447321@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory
|
Список | pgsql-hackers |
Martijn van Oosterhout <kleptog@svana.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. The bgwriter should drop open file references after the next checkpoint, but I don't recall any forcing function for regular backends to close open files. 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? regards, tom lane
В списке pgsql-hackers по дате отправления: