I looked a bit more into the code and it appears to me that the following
are true:
- A separate wal sender process is created on the primary side for each
connected standby.
- The wal sender process terminates (walsender.c / WalSndLoop) when there
is an error to write to the standby's socket.
- I
On Wed, May 29, 2013 at 9:14 AM, Dimitri Fontaine wrote:
> Abhishek Rai writes:
> > SELECT * from pg_stat_replication();
> >
> > I've noticed that when I terminate the standby (cleanly or through kill
> > -9), the result of above function goes from 1 row to zero rows. The
> result
> > comes ba
On Wed, May 29, 2013 at 9:16 AM, Peter Eisentraut wrote:
> On 5/28/13 9:42 PM, Abhishek Rai wrote:
> > Detecting primary health is easy. But what is the best way to know if
> > the standby is live? Since this is not a hot-standby, I cannot send
> > queries to it.
>
> Then how do you define "liv
On 5/28/13 9:42 PM, Abhishek Rai wrote:
> Detecting primary health is easy. But what is the best way to know if
> the standby is live? Since this is not a hot-standby, I cannot send
> queries to it.
Then how do you define "live" for your use case?
> Currently, I'm sending the following query to
Abhishek Rai writes:
> SELECT * from pg_stat_replication();
>
> I've noticed that when I terminate the standby (cleanly or through kill
> -9), the result of above function goes from 1 row to zero rows. The result
> comes back to 1 row when the standby restarts and reconnects. I was
> wondering
Hello Postgres gurus,
I'm writing a thin clustering layer on top of Postgres using the
synchronous replication feature. The goal is to enable HA and survive
permanent loss of a single node. Using an external coordinator
(Zookeeper), one of the nodes is elected as the primary. The primary node
t
