Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
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(). 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

 Simon Riggs 
 PostgreSQL Training, Services and Support

In response to

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2008-09-29 19:42:50
Subject: pg_upgrade performance test
Previous:From: Tom LaneDate: 2008-09-29 16:14:57
Subject: Re: Fatal Errors

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group