On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
> >
> >> So, I'm quite eager to just revert all those lock_twophase_recover()
> >> changes, and always rely on the "grant lock to dummy proc, then
> >> release
> >> it in startup process" method. If we don't want to rely on that,
> >> PostPrepare_Locks is an example of how to transfer lock ownership from
> >> one process to another correctly.
> >
> > Yes, I realised after I wrote it that PostPrepare already does that
> > switch, just been busy with other stuff to switch over the code.
> >
> > I think we do need some special code because of handling whole lock
> > queues. i.e. if there is a backend requesting an AEL but a prepared xact
> > has it, the lock queue will initially be Backend->Startup and needs to
> > end up looking like Backend->DummyProc.
>
> Hmm, dunno about that, but there is one problem with the "grant to dummy
> proc, then release in startup process" approach. What if there isn't
> enough shared memory available to re-acquire the lock for the dummy
> proc? It would be rather unfortunate to throw an error and shut down the
> standby, instead of promoting it to a new master.
Any error would be unfortunate at that point. That particular error
seems unlikely, since we are only talking about AccessExclusiveLocks. If
the server has a problem with that many locks, then it is severely in
danger from prepared transactions in the general case, since such errors
could be also be thrown by the current code in mildly different
circumstances.
Do you see any alternative approaches to the one taken?
I have documented the requirement for max_locks_per_transaction to be as
high or higher than on master, as is the case for other parameters.
> In fact, what happens if you ran out of shared memory when replaying a
> relation_redo_lock record? Panic?
An ERROR in the startup process will cause it to upgrade to FATAL,
AFAIK. That means the server will do a crash shutdown, AIUI. That is the
equivalent of a PANIC, I guess. How else could it behave?
-- Simon Riggs www.2ndQuadrant.com
