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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
