Actual meaning from pg_stat_replication.sync_state potential vs. sync and the usage of synchronous_standby_names

From: Dirk Krautschick <Dirk(dot)Krautschick(at)trivadis(dot)com>
To: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Actual meaning from pg_stat_replication.sync_state potential vs. sync and the usage of synchronous_standby_names
Date: 2020-09-09 09:12:41
Message-ID: AM0PR05MB608250107898F3869B1E7715E9260@AM0PR05MB6082.eurprd05.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hi,

my goal is to create a replication cluster with several nodes and all guaranteed in sync to provide
read only load balancing with exact the same set of data over all nodes.

Basically a pretty well known use case so I set the value for synchronous_standby_names to all
nodes. Maybe with a * or just a list of all nodes.

Now I see in the pg_stat_replication that mostly not all nodes are in sync_state = sync but mostly
in potential. What does potential exactly (need a reliable answer) mean? I would assume that in
this case the WAL information is already streamed to the other node but not applied yet. From
a DR perspective fine but not for my scenario.

So I set the parameter on all nodes synchronous_commit to remote_apply to make sure that every nodes has
to be committed to finish a transaction.

But even then it has the same effect.

But then the weird part….if I set the synchronous_standby_names to something like FIRST 2 ( …list of nodes)
then I reach the state that every node is in sync. So I have to use this way of declaration even if I list every
node in there. Just to say all nodes won’t work. Bug, Feature, works as designed? ☺

Cheers

Dirk

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Karen Jex 2020-09-09 13:32:18 Re: Actual meaning from pg_stat_replication.sync_state potential vs. sync and the usage of synchronous_standby_names
Previous Message Juan José Santamaría Flecha 2020-09-08 10:46:50 Re: Regarding the Spikes in the connection pool on our Database in the particular time period.