Re: bgwriter, inherited temp tables TODO items?
От | Bruce Momjian |
---|---|
Тема | Re: bgwriter, inherited temp tables TODO items? |
Дата | |
Msg-id | 200507211822.j6LIMnY26153@candle.pha.pa.us обсуждение исходный текст |
Ответ на | bgwriter, inherited temp tables TODO items? ("Thomas F. O'Connell" <tfo@sitening.com>) |
Ответы |
Re: bgwriter, inherited temp tables TODO items?
|
Список | pgsql-hackers |
Thomas F. O'Connell wrote: > I'm switching the aftermath of this thread -- http:// > archives.postgresql.org/pgsql-general/2005-07/msg00501.php -- to - > hackers since it raised issues of potential concern to developers. > > At various points in the thread, Tom Lane said the following: > > "I have an old note to myself that persistent write errors could "clog" > the bgwriter, because I was worried that after an error it would > stupidly try to write the same buffer again instead of trying to make > progress elsewhere. (CVS tip might be better about this, I'm not sure.) > A dirty buffer for a file that doesn't exist anymore would certainly > qualify as a persistent failure." > > and > > "Hmm ... a SELECT from one of the "actual tables" would then scan the > temp tables too, no? > > Thinking about this, I seem to recall that we had agreed to make the > planner ignore temp tables of other backends when expanding an > inheritance list --- but I don't see anything in the code implementing > that, so it evidently didn't get done yet." > > I don't immediately see TODO items correpsonding to these. Should > there be some? Or do these qualify as bugs and should they be > submitted to that queue? Would you show a query that causes the problem so I can properly word the TODO item for inheritance and temp tables? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: