Re: On login trigger: take three

> On 28 Mar 2022, at 23:31, Andres Freund <andres@anarazel.de> wrote:
> 
> Hi,
> 
> On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
>>> On 28 Mar 2022, at 19:10, Andres Freund <andres@anarazel.de> wrote:
>>> On 2022-03-28 15:57:37 +0300, a.sokolov@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.
> 
> Maybe side-effects is a bit too general? Emitting a log message, rejecting a
> login, setting some GUCs, etc are all side-effects too.

Good point, it needs to say that modifications that cause WAL to be generated
are prohibited, but in a more user-friendly readable way.  Perhaps in a big red
warning box.

>>>> 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.
> 
> It does seem like a huge footgun. But also kinda useful. So I'm really +-0.

Looks like we are in agreement here.  I'm going to go over it again and sleep
on it some more before the deadline hits.

--
Daniel Gustafsson		https://vmware.com/