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 14:59:50 |
Message-ID: | 1222700390.4445.1269.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2008-09-29 at 10:30 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > Is it possible to have a FATAL error that crashes a backend and for it
> > to *not* have written an abort WAL record for any previously active
> > transaction?
>
> Well, a FATAL error will still go through transaction abort before
> exiting, IIRC. The problem case is a PANIC or an actual core dump.
> > If we either *always* write a WAL record, or PANIC then that
> > makes some coding easier,
>
> Like what?
For constructing snapshots during standby. I need a data structure where
emulated-as-running transactions can live. If backend birth/death is
intimately tied to WAL visible events then I can use dummy PGPROC
structures. If not, then I will have to create a special area that can
expand to cater for the possibility that a backend dies and WAL replay
won't know about it - which also means I would need to periodically dump
a list of running backends into WAL.
PANIC isn't a problem case because we'll end up generating a shutdown
checkpoint which shows the backends have been terminated.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-09-29 15:06:44 | Re: [PATCHES] Infrastructure changes for recovery |
Previous Message | Tom Lane | 2008-09-29 14:30:15 | Re: Fatal Errors |