> On 28 Mar 2022, at 19:10, Andres Freund <and...@anarazel.de> wrote:
> On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
>> + data initialization. It is vital that any event trigger using the
>> + <literal>login</literal> event checks whether or not the database is in
>> + recovery.
>>
>> Does any trigger really have to contain a pg_is_in_recovery() call?
>
> Not *any* trigger, just any trigger that writes.
Thats correct, the docs should be updated with something like the below I
reckon.
It is vital that event trigger using the <literal>login</literal> event
which has side-effects checks whether or not the database is in recovery to
ensure they are not performing modifications to hot standby nodes.
>> In this message
>> (https://www.postgresql.org/message-id/20220312024652.lvgehszwke4hhove%40alap3.anarazel.de)
>> it was only about triggers on hot standby, which run not read-only queries
>
> The problem precisely is that the login triggers run on hot standby nodes, and
> that if they do writes, you can't login anymore.
Do you think this potential foot-gun is scary enough to reject this patch?
There are lots of creative ways to cause Nagios alerts from ones database, but
this has the potential to do so with a small bug in userland code. Still, I
kind of like the feature so I'm indecisive.
--
Daniel Gustafsson https://vmware.com/
