On Fri, 2009-01-09 at 11:20 +0000, Simon Riggs wrote:
> On Fri, 2009-01-09 at 12:33 +0200, Heikki Linnakangas wrote:
> > Simon Riggs wrote:
> > > On Thu, 2009-01-08 at 15:50 -0500, Tom Lane wrote:
> > >> Simon Riggs <simon@2ndQuadrant.com> writes:
> > >>> On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
> > >>>> When a backend dies with FATAL, it writes an abort record before exiting.
> > >>>>
> > >>>> (I was under the impression it doesn't until few minutes ago myself,
> > >>>> when I actually read the shutdown code :-))
> > >>> Not in all cases; keep reading :-)
> > >> If it doesn't, that's a bug. A FATAL exit is not supposed to leave the
> > >> shared state corrupted, it's only supposed to be a forcible session
> > >> termination. Any open transaction should be rolled back.
> > >
> > > Please look back at the earlier discussion we had on this exact point:
> > > http://archives.postgresql.org/pgsql-hackers/2008-09/msg01809.php
> >
> > I think the running-xacts list we dump to WAL at every checkpoint is
> > enough to handle that. Just treat the dead transaction as in-progress
> > until the next running-xacts record. It's presumably extremely rare to
> > have a process die with FATAL, and not write an abort record.
>
> I agree, but I'll wait for Tom to speak further.
OK, will proceed without this. Time is pressing.
Heikki and I both agree that FATAL errors that fail to write abort
records are rare and an acceptable problem in real usage. If they do
occur, their nuisance factor is short-lived because of measures taken
within the patch.
Hot Standby does not *rely* upon there always an abort record for FATAL
errors, so we cannot reasonably say the current design would be
"unacceptably fragile" as I had once thought.
So based upon that, out comes the slotid concept and luckily much of the
cruftier aspects of the patch. Less code, probably fewer bugs. Good
thing.
I will produce a new v7 with those changes and merge the changes for v6b
also, so we can begin review again from there.
Hi ho, hi ho...
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
