On Fri, Oct 13, 2023 at 11:26 AM Alexander Korotkov
<aekorotkov@gmail.com> wrote:
> 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.
I've revised the comments about the lock a bit. I've also run some
tests regarding the connection time (5 runs).
v45, event_triggers=on: avg=3.081ms, min=2.992ms, max=3.146ms
v45, event_triggers=off: avg=3.132ms, min=3.048ms, max=3.186ms
master: 3.080ms, min=3.023ms, max=3.167ms
So, no measurable overhead (not surprising since no extra catalog lookup).
I think this patch is in the commitable shape. Any objections?
------
Regards,
Alexander Korotkov
