From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | qihua wu <staywithpin(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: invisible commit question for sync replication |
Date: | 2023-02-01 08:38:27 |
Message-ID: | 49ef95ee06cb0d94af198cac331f7bc39d743619.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2023-02-01 at 14:52 +0800, qihua wu wrote:
> When run a cluster with sync replication, if DML is done on primary, but primary is
> isolated from all slave, then the DML will hang, if cancel it DML, it will say:
> WARNING: canceling wait for synchronous replication due to user request
> DETAIL: The transaction has already committed locally, but might not have been replicated to the standby
>
> So the workflow is
> 1: commit to local.
> 2: waiting for ACK from remote sync.
>
> When cancel the DML at step 2. the data are arealy on local, that's why it's warning.
>
> But when runs an insert which is waiting for remote ACK, and then query from another
> session, I didn't find that row. Why this happen? If the insert is already one locally,
> whey another session can't read it?
COMMIT is not as atomic as it appears. When the backend is waiting for the standby,
it has already committed the transaction on disk, but that fact is not advertised to
the other backends yet.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | qihua wu | 2023-02-01 09:25:35 | Re: invisible commit question for sync replication |
Previous Message | Kyotaro Horiguchi | 2023-02-01 08:20:53 | Re: How could I elog the tupleTableSlot to the fronted terminal? |