MIME-Version: 1.0
References: <19488-d7ccfca2bf6b74b0@postgresql.org>
 <CAJTYsWUQBwCOQ=uGnLP7C2ofN6TqUpGeOHan2N99mza1DjybsQ@mail.gmail.com>
 <CAHGQGwG=F8_12nPKxUkYm-uS5QFJp+KF=3X5zM2vKP=0SKAeHw@mail.gmail.com>
 <CAPpHfdt_Fj73xYhKtEc66v7c_ZLaUSFqXfCWhRdp3tMX6ksMjQ@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdt_Fj73xYhKtEc66v7c_ZLaUSFqXfCWhRdp3tMX6ksMjQ@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Wed, 20 May 2026 21:05:03 +0900
Message-ID: 
 <CAHGQGwHEVC1181tW78HuotgbF2jMF_59wzKrtS7hFYn_f9tuew@mail.gmail.com>
Subject: Re: BUG #19488: Standby connection fails after dropping on login
 event trigger enabled always
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>, kyzevan23@mail.ru,
	pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwHEVC1181tW78HuotgbF2jMF_59wzKrtS7hFYn_f9tuew%40mail.gmail.com>
Precedence: bulk

On Wed, May 20, 2026 at 8:31=E2=80=AFPM Alexander Korotkov <aekorotkov@gmai=
l.com> wrote:
>
> On Wed, May 20, 2026 at 1:03=E2=80=AFPM Fujii Masao <masao.fujii@gmail.co=
m> wrote:
> > On Wed, May 20, 2026 at 1:37=E2=80=AFPM Ayush Tiwari
> > <ayushtiwari.slg01@gmail.com> wrote:
> > > Thanks for the report and the precise repro.
> >
> > +1
> >
> > > Attached patch adds a RecoveryInProgress() check to skip the cleanup
> > > branch on standbys.
> >
> > Thanks for investigating this issue and for the patch!
> > The patch looks good to me.
> >
> > > I think this needs to be backpatched too.
> >
> > Yes. Seems this should be backpatched to v17, where login event trigger=
s
> > were introduced.
>
> I've added a tap test reproducing the bug.  I'm going to push and
> backpatch this to v17 if no objections.

+# Wait for the standby to replay the CREATE/DROP catalog state.  At
+# this point the standby's pg_database.dathasloginevt is still true.
+$primary->wait_for_replay_catchup($standby);
+
+# A new connection to the standby exercises EventTriggerOnLogin()'s
+# cleanup branch.  With the RecoveryInProgress() guard, that branch is
+# skipped on the standby and the connection succeeds.  Without it the
+# session aborts with a FATAL about AccessExclusiveLock.  Probing the
+# flag itself via safe_psql is what triggers the cleanup path.
+is( $standby->safe_psql(
+ 'postgres',
+ "SELECT dathasloginevt FROM pg_database WHERE datname =3D 'postgres'"),
+ 't',
+ 'standby accepts connection and reports dangling dathasloginevt');

The test looks unstable to me. wait_for_replay_catchup() may connect to
the primary to obtain the flush LSN, which could cause dathasloginevt to
become false before the subsequent safe_psql() call on the standby.

Regards,

--=20
Fujii Masao