Tom Lane wrote:
Fujii Masao <masao.fu...@gmail.com> writes:
On Wed, Feb 4, 2009 at 8:35 PM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
... I'm not sure why we in CVS HEAD we don't reset
FatalError until after the startup process is finished.
Which may repeat the recovery crash and reinitializing forever. To prevent
this problem, unexpected death of startup process should not cause
reinitializing?
Fujii-san has it in one.
In CVS HEAD, we always do ExitPostmaster(1) if the startup process dies
unexpectedly, regardless of FatalError. So it serves no such purpose there.
But yeah, we do have that problem with the patch. What do we want to do
if the startup process dies with FATAL? It seems reasonable to assume
that the problem isn't going to just go away if we restart: we'd do
exactly the same sequence of actions after restart.
But if it's after reaching consistent recovery, the system should still
be in consistent state, and we could stay open for read-only
transactions. That would be useful to recover a corrupted database/WAL;
you could let the WAL replay to run as far as it can, and then connect
and investigate the situation, or run pg_dump.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
