Re: standby registration (was: is sync rep stalled?)
От | Aidan Van Dyk |
---|---|
Тема | Re: standby registration (was: is sync rep stalled?) |
Дата | |
Msg-id | AANLkTinhDMaWs1+YyZca8M19nizbLdYovCq+QeqAKiHv@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: standby registration (was: is sync rep stalled?) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
On Thu, Oct 7, 2010 at 1:27 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Let me check that I got this right, and add some details to make it more > concrete: Each standby is given a name. It can be something like "boston1" > or "testserver". It does *not* have to be unique across all standby servers. > In the master, you have a list of important, synchronous, nodes that must > acknowledge each commit before it is acknowledged to the client. > > The standby name is a GUC in the standby's configuration file: > > standby_name='bostonserver' > > The list of important nodes is also a GUC, in the master's configuration > file: > > synchronous_standbys='bostonserver, oxfordserver' +1. It definitely covers the scenarios I want. And even allows the ones I don't want, and don't understand either ;-) I and personally, I'ld *love* it if the streaming replication protocol was adjusted to that every streaming WAL client reported back their role and recive/fsync/replay positions as part of the protocol (allowing role and positions to be something "NULL"able/empty/0). I think Simon demonstrated that the overhead to report it isn't high. Again, in the deployments I'm wanting, the "slave" isn't a PG server, but something like Magnus's stream-to-archive, so I can't query the slave to see how far behind it is. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: