Re: FATAL: could not open relation pg_tblspc/491086/467369/491103: No such file or directory - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: FATAL: could not open relation pg_tblspc/491086/467369/491103: No such file or directory
Date
Msg-id 1232358547.31669.329.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: FATAL: could not open relation pg_tblspc/491086/467369/491103: No such file or directory  (Gianni Ciolli <gianni.ciolli@2ndquadrant.it>)
Responses Re: FATAL: could not open relation pg_tblspc/491086/467369/491103: No such file or directory  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Fri, 2009-01-16 at 19:12 +0100, Gianni Ciolli wrote:
> On Fri, Jan 16, 2009 at 06:39:11PM +0100, Gianni Ciolli wrote:
> (...)
> > During a Warm Standby session using current HEAD I obtained the
> > following error on the standby node:

I think I understand the cause of these bugs in CVS HEAD now.

In various places in current HEAD we throw a checkpoint when we want to
be certain that all buffers have been flushed.

In recovery, a checkpoint isn't always a restartpoint for two reasons:
timing and rmgr state. This gives both a cause for the error and an
explanation of why it does not occur consistently. ISTM this could
likely effect previous releases as well.

We need to put some marker into WAL to allow the same actions to be
repeated in recovery. We can't just force these "correctness
checkpoints" to be restartpoints because they might be invalid, but we
can force CheckPointGuts() (or something less) without updating the
control file.

With regard to various changes I have in motion, the CheckPointGuts()
would need to be executed in full before further WAL replay occurs, so
would need to be executed by the Startup process and not by the bgwriter
to ensure we performed the correct sequence of actions. 

CHECKPOINT_FORCE might be the right indicator of when to do take special
action in recovery, not sure. Will look at this again later.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: WIP: Automatic view update rules
Next
From: Simon Riggs
Date:
Subject: Re: Hot Standby dev build (v8)