Re: ERROR: could not open relation
| От | Thomas F. O'Connell |
|---|---|
| Тема | Re: ERROR: could not open relation |
| Дата | |
| Msg-id | E5ABD9F7-0B3B-405E-86E9-E7CCF2F9E8BA@sitening.com обсуждение исходный текст |
| Ответ на | Re: ERROR: could not open relation (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: ERROR: could not open relation
|
| Список | pgsql-general |
From this thread, these two bits about PostgreSQL stand out: "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? Thanks again to all developers and community folk who lent insight into this error -- diagnosis and recovery (which was, thankfully, virtually non-existent). -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open Source: Open Your i™ http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-260-0005
В списке pgsql-general по дате отправления: