On Mon, 2008-09-29 at 11:18 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.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.
Few thoughts:
* 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
> restart?
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.comPostgreSQL Training, Services and Support
