Re: Fatal Errors

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fatal Errors
Date: 2008-09-29 17:06:20
Message-ID: 1222707980.4445.1295.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Mon, 2008-09-29 at 12:14 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > * Might we make AbortTransaction critical just as far as the
> > END_CRIT_SECTION after XLogInsert in RecordTransactionAbort(), but no
> > further? Don't expect yes, but seems worth recording thoughts.
>
> The problem is that pretty much everything that proc_exit runs would
> have to become critical, AFAICS. And a lot of that code is explicitly
> intended not to be critical --- that's why we split it up into multiple
> proc_exit callbacks. If one fails we pick up with the next, after a
> recursive call to elog().

OK...next idea. If we didn't PANIC, then Postmaster knows about child
death and fumbles around with the ProcArray.

Will it be OK to simply WAL log ProcArrayAdd() and ProcArrayRemove()?

Methinks postmaster can't do this. But might be able to ask somebody
else to do it for him?

The next person to run ProcArrayAdd() could be left a message to say
last user of this proc index didn't clean up and we need to log it. That
way we can WAL log the ProcArrayRemove() and the ProcArrayAdd() in one
message.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-09-29 19:42:50 pg_upgrade performance test
Previous Message Tom Lane 2008-09-29 16:14:57 Re: Fatal Errors