On Mon, 2008-09-29 at 11:18 -0400, Tom Lane wrote:
> 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.
Aware of possibility fragility, hence the post.
* Is it close enough that we can get away with having a few spare slots
to cater for that possibility?
* 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.
> > 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
Yes, but if I do there would still be a WAL record of some kind there to
allow us to confirm the change of tli.
Anyway, I thought you wanted me to keep it now?
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2008-09-29 15:54:55|
|Subject: Re: [PATCHES] Infrastructure changes for recovery|
|Previous:||From: Tom Lane||Date: 2008-09-29 15:24:08|
|Subject: Re: [PATCHES] Infrastructure changes for recovery |