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

From Alexander Korotkov
Subject Re: On login trigger: take three
Date
Msg-id CAPpHfdsVgL6cb4a60oXH5aydXMVF5Z2sgBc1_MsobVibREJYAA@mail.gmail.com
Whole thread Raw
In response to Re: On login trigger: take three  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: On login trigger: take three  (Andres Freund <andres@anarazel.de>)
Re: On login trigger: take three  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi!

On Tue, Oct 3, 2023 at 8:35 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> Thank you for the interesting ideas. I'd like to try to revive the
> version with the flag in pg_database.  Will use other ideas as backup
> if no success.

I've revived the patch version with pg_database.dathasloginevt flag.
I took v32 version [1] and made the following changes.

 * Incorporate enchantments made on flagless version of patch.
 * Read dathasloginevt during InitPostgres() to prevent extra catalog
access and even more notable StartTransactionCommand() when there are
no login triggers.
 * Hold lock during setting of pg_database.dathasloginevt flag (v32
version actually didn't prevent race condition).
 * Fix AlterEventTrigger() to check event name not trigger name
 * Acquire conditional lock while resetting pg_database.dathasloginevt
flag to prevent new database connection to hang waiting another
transaction to finish.

This version should be good and has no overhead.  Any thoughts?
Daniel, could you please re-run the performance tests?

Links
1. https://www.postgresql.org/message-id/CAMEv5_vDjceLr54WUCNPPVsJs8WBWWsRW826VppNEFoLC1LAEw%40mail.gmail.com

------
Regards,
Alexander Korotkov



pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: A failure in 031_recovery_conflict.pl on Debian/s390x
Next
From: Jelte Fennema
Date:
Subject: Re: Request for comment on setting binary format output per session