Re: On login trigger: take three

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Greg Nancarrow <gregn4422(at)gmail(dot)com>, Ivan Panchenko <wao(at)mail(dot)ru>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: On login trigger: take three
Date: 2022-03-13 22:31:03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 12 Mar 2022, at 03:46, Andres Freund <andres(at)anarazel(dot)de> wrote:

>> + <para>
>> + The <literal>login</literal> event occurs when a user logs in to the
>> + system.
>> + Any bugs in a trigger procedure for this event may prevent successful
>> + login to the system. Such bugs may be fixed after first restarting the
>> + system in single-user mode (as event triggers are disabled in this mode).
>> + See the <xref linkend="app-postgres"/> reference page for details about
>> + using single-user mode.
>> + </para>
> I'm strongly against adding any new dependencies on single user mode.
> A saner approach might be a superuser-only GUC that can be set as part of the
> connection data (e.g. PGOPTIONS='-c ignore_login_event_trigger=true').

This, and similar approaches, has been discussed in this thread. I'm not a fan
of holes punched with GUC's like this, but if you plan on removing single-user
mode (as I recall seeing in an initdb thread) altogether then that kills the
discussion. So.

Since we already recommend single-user mode to handle broken event triggers, we
should IMO do something to cover all of them rather than risk ending up with
one disabling GUC per each event type. Right now we have this on the CREATE
EVENT TRIGGER reference page:

"Event triggers are disabled in single-user mode (see postgres). If an
erroneous event trigger disables the database so much that you can't even
drop the trigger, restart in single-user mode and you'll be able to do

Something like a '-c ignore_event_trigger=<event|all>' GUC perhaps?

Daniel Gustafsson

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2022-03-13 22:40:18 Re: BufferAlloc: don't take two simultaneous locks
Previous Message Yura Sokolov 2022-03-13 22:27:47 Re: BufferAlloc: don't take two simultaneous locks