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