Re: Postmaster holding unlinked files for pg_largeobject table

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, 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:49:46Z
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.

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jun 6, 2011 at 12:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> On reflection I think this behavior is probably limited to the case
>> where we've done what we used to call a "blind write" of a block that
>> is unrelated to our database or tables. For normal SQL-driven accesses,
>> there's a relcache entry, and flushing of that entry will lead to
>> closure of associated files. I wonder whether we should go back to
>> forcibly closing the FD after a blind write. This would suck if a
>> backend had to do many dirty-buffer flushes for the same relation,
>> but hopefully the bgwriter is doing most of those. We'd want to make
>> sure such forced closure *doesn't* occur in the bgwriter. (If memory
>> serves, it has a checkpoint-driven closure mechanism instead.)

> Instead of closing them immediately, how about flagging the FD and
> closing all the flagged FDs at the end of each query, or something
> like that?

Hmm, there's already a mechanism for closing "temp" FDs at the end of a
query ... maybe blind writes could use temp-like FDs?

			regards, tom lane