Re: On login trigger: take three

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Mikhail Gribkov <youzhick@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Greg Nancarrow <gregn4422@gmail.com>, Ivan Panchenko <wao@mail.ru>, Teodor Sigaev <teodor@sigaev.ru>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, vignesh C <vignesh21@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2023-10-12T17:34:57Z
Lists: pgsql-hackers
On Tue, Oct 10, 2023 at 3:43 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> Yep, in v43 it worked that way.  One transaction has to wait for
> another finishing update of pg_database tuple, then fails.  This is
> obviously ridiculous.  Since overlapping setters of flag will have to
> wait anyway, I changed lock mode in v44 for them to
> AccessExclusiveLock.  Now, waiting transaction then sees the updated
> tuple and doesn't fail.

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?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



Commits

  1. Fix some typos in event trigger docs

  2. Use heap_inplace_update() to unset pg_database.dathasloginevt

  3. Remove the flaky check in event_trigger_login regression test

  4. Fix instable 006_login_trigger.pl test

  5. Add support event triggers on authenticated login

  6. Add GUC for temporarily disabling event triggers

  7. Fix typo in reference to __FreeBSD__.

  8. Restore robustness of TAP tests that wait for postmaster restart.

  9. Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.