On Sun, 2009-11-15 at 16:50 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
> >> - If WAL recovery runs out of lock space while acquiring an
> >> AccessExclusiveLock on behalf of a transaction that ran in the master,
> >> it will FATAL and abort recovery, bringing down the standby. Seems like
> >> it should wait/cancel queries instead.
> >
> > Hard resources will always be an issue. If the standby has less than it
> > needs, then there will be problems. All of those can be corrected by
> > increasing the resources on the standby and restarting. This effects
> > max_connections, max_prepared_transactions, max_locks_per_transaction,
> > as documented.
>
> There's no safe setting for those that would let you avoid the issue. No
> matter how high you set them, it will be possible for read-only backends
> to consume all the lock space, causing recovery to abort and bring down
> the standby.
It can still fail even after we kick everybody off. So why bother? Most
people run nowhere near the size limit of their lock tables, and on the
standby we only track AccessExclusiveLocks in the Startup process. We
gain little by spending time on partial protection against an unlikely
issue.
(BTW, I'm not suggesting you commit HS immediately. Only that we split
into phases, stabilise and test pase 1 soon, then fix the remaining
issues later.)
-- Simon Riggs www.2ndQuadrant.com