Abhishek Rai <abhishekrai@gmail.com> 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 if there is any kind of guarantee about the results of > pg_stat_replication as the standby suffers a network partition, and/or > restarts and reconnects with the primary. Are there any parameters that > control this behavior?
Not that I know of. We don't register standbies at all, so the master only knows about those which are successfully connected now.
Actually that is precisely what I need. If the master reports via pg_stat_replication the set of standbies that it is connected to, then the clustering software can just rely on it to know if standby is active or not. However, this information is not very useful until there are some guarantees on how long it would take for the response of pg_stat_replication to be updated in response to an event. Without that, the clustering software would not know how long to wait before declaring the standby unhealthy. It's not a requirement that the timeout be configurable, as long as it's deterministic.
Thanks for your help! Abhishek
Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
