Re: WIP: Failover Slots
| От | Craig Ringer |
|---|---|
| Тема | Re: WIP: Failover Slots |
| Дата | |
| Msg-id | CAMsr+YFXqkAUVF8p6KxkYX1thAddWifm5SeW_8xTJJF8wtC4PA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: WIP: Failover Slots (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: WIP: Failover Slots
|
| Список | pgsql-hackers |
On 23 January 2016 at 00:51, Andres Freund <andres@anarazel.de> wrote:
Not propagating them through the WAL also has the rather large advantage
of not barring the way to using such slots on standbys.
Yeah. So you could have a read-replica that has a slot and it has child nodes you can fail over to, but you don't have to have the slot on the master.
I don't personally find that to be a particularly compelling thing that says "we must have this" ... but maybe I'm not seeing the full significance/advantages.
I think it's technically quite possible to maintain the required
resources on multiple nodes. The question is how would you configure on
which nodes the resources need to be maintained? I can't come up with a
satisfying scheme...
BTW, I'm keeping a working tree at https://github.com/2ndQuadrant/postgres/tree/dev/failover-slots . Subject to rebasing, history not clean. It has a test script in it that'll go away before patch posting.
Current state needs work to ensure that on-disk and in-memory representations are kept in sync, but is getting there.
В списке pgsql-hackers по дате отправления: