Horton

Re: Postmaster holding unlinked files for pg_largeobject table

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Kevin Grittner <kevin.grittner@wicourts.gov>, alexk <alexk@commandprompt.com>, Alexander Shulgin <ash@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-06T16:10:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Reset reindex-in-progress state before reverifying an exclusion constraint.

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