Excerpts from Tom Lane's message of lun jun 06 12:49:46 -0400 2011: > Robert Haas <robertmh...@gmail.com> writes: > > On Mon, Jun 6, 2011 at 12:30 PM, Tom Lane <t...@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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
