Re: Postmaster holding unlinked files for pg_largeobject table
От | Tom Lane |
---|---|
Тема | Re: Postmaster holding unlinked files for pg_largeobject table |
Дата | |
Msg-id | 8653.1307378986@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Postmaster holding unlinked files for pg_largeobject table (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Postmaster holding unlinked files for pg_largeobject table
Re: Postmaster holding unlinked files for pg_largeobject table |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: