On Thu, 2009-10-22 at 07:55 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
> >> 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.
>
> Note that read-only backends also occupy lock space when they run
> queries, taking AccessShareLocks.
>
> > Do you see any alternative approaches to the one taken?
>
> Making some effort to transfer locks instead of acquiring+releasing
> would eliminate the need for having extra lock space available when
> switching from hot standby mode to normal operation.
This isn't very clear. You started by saying you were quite eager to
always grant and then release; this sounds like you don't want that now,
but you now again like the approach I had already attempted to take.
Please explain a little more.
Well spotted on the pending bug, BTW.
-- Simon Riggs www.2ndQuadrant.com