Re: Postmaster holding unlinked files for pg_largeobject table

Excerpts from Tom Lane's message of lun jun 06 12:49:46 -0400 2011:
> 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?

OK, I'll have a look at how blind writes work this afternoon and propose
something.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support