From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: standby registration (was: is sync rep stalled?) |
Date: | 2010-10-07 17:59:23 |
Message-ID: | AANLkTinhDMaWs1+YyZca8M19nizbLdYovCq+QeqAKiHv@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 7, 2010 at 1:27 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-10-07 18:05:51 | Issues with two-server Synch Rep |
Previous Message | Josh Berkus | 2010-10-07 17:59:06 | Re: Issues with Quorum Commit |