Standalone backends run StartupXLOG in an incorrect environment - Mailing list pgsql-hackers

From Tom Lane
Subject Standalone backends run StartupXLOG in an incorrect environment
Date
Msg-id 16809.1253380870@sss.pgh.pa.us
Whole thread Raw
Responses Re: Standalone backends run StartupXLOG in an incorrect environment
Re: Standalone backends run StartupXLOG in an incorrect environment
List pgsql-hackers
I realized the truth of $SUBJECT while reading this report:
http://archives.postgresql.org/pgsql-general/2009-09/msg00712.php

In a standalone backend, postgres.c tries to run StartupXLOG after
having done only BaseInit(), which means that we don't have a PGPROC
(hence can't take LWLocks much less heavyweight locks) and we have not
totally finished initializing the bufmgr either.  This is apparently
enough for the "normal" case where there's no log replay to do; but
as the above report shows, it's completely inadequate for some of the
more complex code paths in replay.  I suspect this has been broken
from the beginning.

Fixing this will require rearranging things around InitPostgres
(in particular, I think InitBufferPoolBackend will have to be
called directly from postgres.c).  Since that code got rearranged
quite a bit last month, I'd be hesitant to try to back-patch whatever
fix we come up with for HEAD.  Seeing that we'd never noticed the
problem before, I think it's okay to fix it just in HEAD and not
risk back-patching ... comments?

Also, does this have any impact on the Hot Standby stuff?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Crypto
Next
From: Marcos Luis Ortiz Valmaseda
Date:
Subject: Re: Crypto