Re: On login trigger: take three - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: On login trigger: take three
Date
Msg-id CAPpHfdtOd2eiyE_wN2rfWconeH0BR3gk2n_uQWf6RQvBDvpPBg@mail.gmail.com
Whole thread Raw
In response to Re: On login trigger: take three  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: On login trigger: take three  (Alexander Korotkov <aekorotkov@gmail.com>)
List pgsql-hackers
On Fri, Oct 13, 2023 at 4:18 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > On Thu, Oct 12, 2023 at 8:35 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> > > Doesn't that mean that if you create the first login trigger in a
> > > database and leave the transaction open, nobody can connect to that
> > > database until the transaction ends?
> >
> > It doesn't mean that, because when trying to reset the flag v44 does
> > conditional lock.  So, if another transaction is holding the log we
> > will just skip resetting the flag.  So, the flag will be cleared on
> > the first connection after that transaction ends.
>
> But in the scenario I am describing the flag is being set, not reset.

Sorry, it seems I just missed some logical steps.  Imagine, that
transaction A created the first login trigger and hangs open.  Then
the new connection B sees no visible triggers yet, but dathasloginevt
flag is set.  Therefore, connection B tries conditional lock but just
gives up because the lock is held by transaction A.

Also, note that the lock has been just some lock with a custom tag.
It doesn't effectively block the database.  You may think about it as
of custom advisory lock.

------
Regards,
Alexander Korotkov



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_stat_statements and "IN" conditions
Next
From: Dilip Kumar
Date:
Subject: Re: pg_upgrade's interaction with pg_resetwal seems confusing