Re: Hot standby, prepared xacts, locks
От | Simon Riggs |
---|---|
Тема | Re: Hot standby, prepared xacts, locks |
Дата | |
Msg-id | 1256191452.492.6963.camel@ebony обсуждение исходный текст |
Ответ на | Re: Hot standby, prepared xacts, locks (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Hot standby, prepared xacts, locks
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: