Re: invisible commit question for sync replication

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: qihua wu <staywithpin(at)gmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: invisible commit question for sync replication
Date: 2023-02-01 07:21:25
Message-ID: CAKFQuwYRpjQNz8EYe=hKdqEP1XE+KsDoXRY5MB8_+JEv-OLgtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wednesday, February 1, 2023, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:

> Hi,
>
> On Wed, Feb 01, 2023 at 02:52:49PM +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?
>
> It works as expected for me, are you sure both sessions are actually
> connected
> to the same server and/or querying the same table?
>
> [1456]rjuju(at)127(dot)0(dot)0(dot)1:14295) rjuju=# select * from tt;
> id | val
> ----+-----
> (0 rows)
>
> [1456]rjuju(at)127(dot)0(dot)0(dot)1:14295) rjuju=# insert into tt select 1;
> ^CCancel request sent
> WARNING: 01000: 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.
> LOCATION: SyncRepWaitForLSN, syncrep.c:287
> INSERT 0 1
>
> [1456]rjuju(at)127(dot)0(dot)0(dot)1:14295) rjuju=# select pg_backend_pid(), * from tt;
> pg_backend_pid | id | val
> ----------------+----+--------
> 1456 | 1 | <NULL>
> (1 row)
>
>
> and another session:
>
> [3327]rjuju(at)127(dot)0(dot)0(dot)1:14295) rjuju=# select pg_backend_pid(), * from tt;
> pg_backend_pid | id | val
> ----------------+----+--------
> 3327 | 1 | <NULL>
> (1 row)
>
>
>
This wasn’t the question though. Can the second session see the inserted
row before you cancel the insert that is waiting for sync ack?

Supposedly it can (not able to test myself). Basically, the primary waits
to make the local transaction visible until either sync ack or until the
wait for sync ack is cancelled. It doesn’t make sense to make it visible
while waiting for sync ack since that would defeat the very behavior sync
ack provides for.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message qihua wu 2023-02-01 08:05:14 Re: invisible commit question for sync replication
Previous Message Julien Rouhaud 2023-02-01 07:11:28 Re: invisible commit question for sync replication