Re: Summary and Plan for Hot Standby
От | Robert Haas |
---|---|
Тема | Re: Summary and Plan for Hot Standby |
Дата | |
Msg-id | 603c8f070911150818x60fd001dl7052a9fd20bd57fd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Summary and Plan for Hot Standby (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Summary and Plan for Hot Standby
|
Список | pgsql-hackers |
On Sun, Nov 15, 2009 at 9:50 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 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. OK, but... there will always be things that will bring down the stand-by, just as there will always be things that can bring down the primary. A bucket of ice-water will probably do it, for example. I mean, it would be great to make it better, but is it so bad that we can't postpone that improvement to a follow-on patch? It's not clear to me that it is. I think we should really focus in on things that are likely to make this (1) give wrong answers or (2) won't be able to be fixed in a follow-on patch if they're not right in the original one. Only one or two of the items on your list of additional TODOs seem like they might fall into category (2), and none of them appear to fall into category (1). I predict that if we commit a basic version of this with some annoying limitations for 8.5, people who need the feature will start writing patches to address some of the limitations. No one else is going to undertake any serious development work as long as this remains outside the main tree, for fear of everything changing under them and all their work being wasted. I would like this feature to be as good as possible, but I would like to have it at all more. ...Robert
В списке pgsql-hackers по дате отправления: