Hi, On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote: > > 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.
Maybe side-effects is a bit too general? Emitting a log message, rejecting a login, setting some GUCs, etc are all side-effects too. > >> 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. Greetings, Andres Freund