Re: Postmaster holding unlinked files for pg_largeobject table
От | Tom Lane |
---|---|
Тема | Re: Postmaster holding unlinked files for pg_largeobject table |
Дата | |
Msg-id | 7833.1307376624@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Postmaster holding unlinked files for pg_largeobject table (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Postmaster holding unlinked files for pg_largeobject table
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Excerpts from Kevin Grittner's message of lun jun 06 11:58:51 -0400 2011: >> Alvaro Herrera <alvherre@commandprompt.com> wrote: >>> What we found out after more careful investigation is that the >>> file is kept open by a backend connected to a different database. >>> I have a suspicion that what happened here is that this backend >>> was forced to flush out a page from shared buffers to read some >>> other page; and it was forced to do a fsync of this file. And >>> then it forgets to close the file descriptor. It doesn't "forget" to close the descriptor; it intentionally keeps it for possible further use. >> This sounds vaguely similar to what I found with WAL files being >> held open for days after they were deleted by read-only backends: >> http://archives.postgresql.org/message-id/15412.1259630304@sss.pgh.pa.us >> I mention it only because there might be one place to fix both.... > Hmm interesting. I don't think the placement suggested by Tom would be > useful, because the Zabbix backends are particularly busy all the time, > so they wouldn't run ProcessCatchupEvent at all. Yeah, I wasn't that thrilled with the suggestion either. But we can't just have backends constantly closing every open FD they hold, or performance will suffer. I don't see any very good place to do this... regards, tom lane
В списке pgsql-hackers по дате отправления: