Re: ERROR: could not open relation

From: "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PgSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: ERROR: could not open relation
Date: 2005-07-14 21:44:19
Message-ID: E5ABD9F7-0B3B-405E-86E9-E7CCF2F9E8BA@sitening.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Mitchell 2005-07-14 21:53:30 Re: Stopping Postgres
Previous Message Karsten Hilbert 2005-07-14 21:42:48 Re: chosing a database name