public inbox for [email protected]
help / color / mirror / Atom feedFrom: Xuneng Zhou <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Chao Li <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: jian he <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: Yura Sokolov <[email protected]>
Subject: Re: Implement waiting for wal lsn replay: reloaded
Date: Tue, 6 Jan 2026 23:58:18 +0800
Message-ID: <CABPTF7W+JKqF4B8p7M5qOgS1Asc1DZWvkDqSwtsqYw5zch1P0w@mail.gmail.com> (raw)
In-Reply-To: <CAPpHfduOE+P3YPfSWF8vSQEj+gBEBVq_N6w0PVZdMqO2sA7Grw@mail.gmail.com>
References: <CABPTF7Xs-64GQNjmbimZNhj2YSKbBny+evz6=cp3X2fkJS+vMQ@mail.gmail.com>
<[email protected]>
<CAPpHfduDVNo4VXgnQFZUg9=2yHQJfUUqjokbi3qVxuJiKNfcwg@mail.gmail.com>
<CABPTF7UkwQZGx5ub731Q+=+rU8yx4ruqMdDt__L_dm9_32LsMw@mail.gmail.com>
<CAPpHfds-KiZRuCruc0jHxLSxLqzKcHJGwOFFA0b_RgaJvtUOEQ@mail.gmail.com>
<CABPTF7Vy4A0S0W7=B-fVd9Bo_15XG_FRYfKUF2CB_i=5svwEZQ@mail.gmail.com>
<CA+hUKG+L0OQR8dQtsNBSaA3FNNyQeFabdeRVzurm0b7Xtp592g@mail.gmail.com>
<CABPTF7V0ryh6D3SByYCBGuWreTKrg3h0icV5tiFbwJ5YibeV+g@mail.gmail.com>
<CAPpHfdudx4kzV58T0LNZyj+HdYA8bmsgkB+j5x6d9fxCWpdRMA@mail.gmail.com>
<CABPTF7UtCZW4EcOaTDnBgMxmdsx9RS_d5Q+LbfroQYLzK2g__A@mail.gmail.com>
<CAPpHfduOE+P3YPfSWF8vSQEj+gBEBVq_N6w0PVZdMqO2sA7Grw@mail.gmail.com>
Hi,
On Tue, Jan 6, 2026 at 11:34 PM Alexander Korotkov <[email protected]> wrote:
>
> On Tue, Jan 6, 2026 at 3:12 PM Xuneng Zhou <[email protected]> wrote:
> >
> > Hi,
> >
> > On Tue, Jan 6, 2026 at 7:54 PM Alexander Korotkov <[email protected]> wrote:
> > >
> > > On Tue, Jan 6, 2026 at 9:29 AM Xuneng Zhou <[email protected]> wrote:
> > > > On Tue, Jan 6, 2026 at 1:43 PM Thomas Munro <[email protected]> wrote:
> > > > > Could this be causing the recent flapping failures on CI/macOS in
> > > > > recovery/031_recovery_conflict? I didn't have time to dig personally
> > > > > but f30848cb looks relevant:
> > > > >
> > > > > Waiting for replication conn standby's replay_lsn to pass 0/03467F58 on primary
> > > > > error running SQL: 'psql:<stdin>:1: ERROR: canceling statement due to
> > > > > conflict with recovery
> > > > > DETAIL: User was or might have been using tablespace that must be dropped.'
> > > > > while running 'psql --no-psqlrc --no-align --tuples-only --quiet
> > > > > --dbname port=25195
> > > > > host=/var/folders/g9/7rkt8rt1241bwwhd3_s8ndp40000gn/T/LqcCJnsueI
> > > > > dbname='postgres' --file - --variable ON_ERROR_STOP=1' with sql 'WAIT
> > > > > FOR LSN '0/03467F58' WITH (MODE 'standby_replay', timeout '180s',
> > > > > no_throw);' at /Users/admin/pgsql/src/test/perl/PostgreSQL/Test/Cluster.pm
> > > > > line 2300.
> > > > >
> > > > > https://cirrus-ci.com/task/5771274900733952
> > > > >
> > > > > The master branch in time-descending order, macOS tasks only:
> > > > >
> > > > > task_id | substring | status
> > > > > ------------------+-----------+-----------
> > > > > 6460882231754752 | c970bdc0 | FAILED
> > > > > 5771274900733952 | 6ca8506e | FAILED
> > > > > 6217757068361728 | 63ed3bc7 | FAILED
> > > > > 5980650261446656 | ae283736 | FAILED
> > > > > 6585898394976256 | 5f13999a | COMPLETED
> > > > > 4527474786172928 | 7f9acc9b | COMPLETED
> > > > > 4826100842364928 | e8d4e94a | COMPLETED
> > > > > 4540563027918848 | b9ee5f2d | FAILED
> > > > > 6358528648019968 | c5af141c | FAILED
> > > > > 5998005284765696 | e212a0f8 | COMPLETED
> > > > > 6488580526178304 | b85d5dc0 | FAILED
> > > > > 5034091344560128 | 7dc95cc3 | ABORTED
> > > > > 5688692477526016 | bb048e31 | COMPLETED
> > > > > 5481187977723904 | d351063e | COMPLETED
> > > > > 5101831568752640 | f30848cb | COMPLETED <-- the change
> > > > > 6395317408497664 | 3f33b63d | COMPLETED
> > > > > 6741325208354816 | 877ae5db | COMPLETED
> > > > > 4594007789010944 | de746e0d | COMPLETED
> > > > > 6497208998035456 | 461b8cc9 | COMPLETED
> > > >
> > > > Thanks for raising this issue. I think it is related to f30848cb after
> > > > some analysis. I'll prepare a follow-up patch to fix it.
> > >
> > > Sorry, I've mistakenly referenced this report from commit [1]. I
> > > thought it was related, but it appears to be not. [1] is related to
> > > the report I've got from Ruikai Peng off-list.
> > >
> > > Regarding the present failure, could it happen before ExecWaitStmt()
> > > calls PopActiveSnapshot() and InvalidateCatalogSnapshot()? If so, we
> > > should do preliminary efforts to release these snapshots.
> > >
> > > 1. https://git.postgresql.org/pg/commitdiff/bf308639bfcfa38541e24733e074184153a8ab7f
> > >
> >
> > I agree that moving PopActiveSnapshot() and
> > InvalidateCatalogSnapshot() to the very beginning of ExecWaitStmt()
> > appears to be a sensible optimization. However, in this particular
> > failure scenario, it may not address the issue.
> >
> > For tablespace conflicts, recovery conflict resolution uses
> > GetConflictingVirtualXIDs(InvalidTransactionId, InvalidOid), which
> > returns all active backends, regardless of their snapshot state. As a
> > result, even if all snapshots are released at the start of
> > ExecWaitStmt(), the session would still be canceled during replay of
> > DROP TABLESPACE.
>
> GetConflictingVirtualXIDs() uses proc->xmin to detect the conflicts.
> ExecWaitStmt() asserts MyProc->xmin == InvalidTransactionId after
> releasing all the snapshots. I still think this happens because
> conflict handling happens before ExecWaitStmt() manages to release the
> snapshots.
>
I did not notice this message before. I'll look more closely at this case.
--
Best,
Xuneng
view thread (12+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Implement waiting for wal lsn replay: reloaded
In-Reply-To: <CABPTF7W+JKqF4B8p7M5qOgS1Asc1DZWvkDqSwtsqYw5zch1P0w@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox