From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | P C <puravc(at)gmail(dot)com> |
Cc: | "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Synchronous Replication: Where is data visible first? |
Date: | 2024-01-11 06:43:50 |
Message-ID: | CAKFQuwYUpW=LVcmjte1tqS9OhoskvFLPwLoxoMtnw8o5tW4UOw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Wednesday, January 10, 2024, P C <puravc(at)gmail(dot)com> wrote:
> Hello,
>
> While discussing with the development team, an interesting question came
> up: in a synchronous streaming replication scenario, with
> synchronous_commit = remote_apply, will the change be first visible on
> Standby (replica)? Primary will wait till the change is applied and
> committed on standby, and hence logically this looks to be correct. But I
> couldn't find this mentioned explicitly anywhere and hence seeking comments
> from the community.
>
IIUC, no, the standbys can never reflect a newer state than what would be
seen on the primary. The state of a given transaction, including most
importantly the locking surrounding it, exists first on the primary and
then is replicated to the secondary. Either the locking will prevent a
dirty read or the dirty read will see the unconfirmed but committed data on
the primary. The locking will be removed on the primary strictly before
the standbys.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Akheel TechDL | 2024-01-11 12:07:46 | Cascading a logical standby for physical replication |
Previous Message | P C | 2024-01-11 06:00:17 | Synchronous Replication: Where is data visible first? |