From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fatal Errors |
Date: | 2008-09-29 15:18:19 |
Message-ID: | 12335.1222701499@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Mon, 2008-09-29 at 10:30 -0400, Tom Lane wrote:
>> 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.
Mph. I find the idea of assuming that there must be an abort record to
be unacceptably fragile. Consider the possibility that the transaction
gets an error while trying to run AbortTransaction. Some of that code
is a CRITICAL_SECTION, but I don't think I like the idea that all of it
has to be one.
> PANIC isn't a problem case because we'll end up generating a shutdown
> checkpoint which shows the backends have been terminated.
Thought you were trying to get rid of the shutdown checkpoint during
restart?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-29 15:24:08 | Re: [PATCHES] Infrastructure changes for recovery |
Previous Message | Simon Riggs | 2008-09-29 15:06:44 | Re: [PATCHES] Infrastructure changes for recovery |