Re: On login trigger: take three

On Sat, Oct 14, 2023 at 2:10 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> 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?

The attached revision fixes test failures spotted by
commitfest.cputube.org.  Also, perl scripts passed perltidy.

------
Regards,
Alexander Korotkov