Horton

Re: On login trigger: take three

Konstantin Knizhnik <k.knizhnik@postgrespro.ru>

View thread View on postgr.es
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Greg Nancarrow <gregn4422@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-12-10T15:48:49Z
Lists: pgsql-hackers 

On 10.12.2020 18:12, Pavel Stehule wrote:
>
> My idea was a little bit different. Inside postinit initialize some 
> global variables with info if there are event triggers or not. And 
> later you can use this variable to start transactions and  other things.
>
> There will be two access to pg_event_trigger, but it can eliminate 
> useless and probably more expensive start_transaction and end_transaction.
>


Do you mean some variable in shared memory or GUCs?
It was my first idea - to use some flag in shared memory to make it 
possible fast check that there are not event triggers.
But this flag should be sent per database. May be I missed something, 
but there is no any per-database shared memory  data structure in Postgres.
Certainly it is possible to organize some hash db->event_info, but it 
makes this patch several times more complex.

 From my point of view it is better to have separate GUC disabling just 
client connection events and switch it on by default.
So only those who need this events with switch it on, other users will 
not pay any extra cost for it.

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.