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

From Daniel Gustafsson
Subject Re: On login trigger: take three
Date
Msg-id 506F25C0-14F7-46FC-AF48-3DBA05550A19@yesql.se
Whole thread Raw
In response to Re: On login trigger: take three  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: On login trigger: take three  (Alexander Korotkov <aekorotkov@gmail.com>)
Re: On login trigger: take three  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
> On 28 Sep 2023, at 23:50, Alexander Korotkov <aekorotkov@gmail.com> wrote:

> I don't think I can reproduce the performance regression pointed out
> by Pavel Stehule [1].

> I can't confirm the measurable overhead.


Running the same pgbench command on my laptop looking at the average connection
times, and the averaging that over five runs (low/avg/high) I see ~5% increase
over master with the patched version (compiled without assertions and debug):

Patched event_triggers on:  6.858 ms/7.038 ms/7.434 ms
Patched event_triggers off: 6.601 ms/6.958 ms/7.539 ms
Master:                     6.676 ms/6.697 ms/6.760 ms

This is all quite unscientific with a lot of jitter so grains of salt are to be
applied, but I find it odd that you don't see any measurable effect.  Are you
seeing the same/similar connection times between master and with this patch
applied?

A few small comments on the patch:

+     prevent successful login to the system. Such bugs may be fixed by
+     restarting the system in single-user mode (as event triggers are
This paragraph should be reworded to recommend the GUC instead of single-user
mode (while retaining mention of single-user mode, just not as the primary
option).


+     Also, it's recommended to evade long-running queries in
s/evade/avoid/ perhaps?


Thanks for working on this!

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Remove MSVC scripts from the tree
Next
From: Daniel Gustafsson
Date:
Subject: Re: Testing autovacuum wraparound (including failsafe)