pgsql: Escalate ERRORs during async notify processing to FATAL

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Escalate ERRORs during async notify processing to FATAL
Date: 2025-11-12 19:16:38
Message-ID: E1vJGKc-006HeO-2C@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Escalate ERRORs during async notify processing to FATAL

Previously, if async notify processing encountered an error, we would
report the error to the client and advance our read position past the
offending entry to prevent trying to process it over and over
again. Trying to continue after an error has a few problems however:

- We have no way of telling the client that a notification was
lost. They get an ERROR, but that doesn't tell you much. As such,
it's not clear if keeping the connection alive after losing a
notification is a good thing. Depending on the application logic,
missing a notification could cause the application to get stuck
waiting, for example.

- If the connection is idle, PqCommReadingMsg is set and any ERROR is
turned into FATAL anyway.

- We bailed out of the notification processing loop on first error
without processing any subsequent notifications. The subsequent
notifications would not be processed until another notify interrupt
arrives. For example, if there were two notifications pending, and
processing the first one caused an ERROR, the second notification
would not be processed until someone sent a new NOTIFY.

This commit changes the behavior so that any ERROR while processing
async notifications is turned into FATAL, causing the client
connection to be terminated. That makes the behavior more consistent
as that's what happened in idle state already, and terminating the
connection is a clear signal to the application that it might've
missed some notifications.

The reason to do this now is that the next commits will change the
notification processing code in a way that would make it harder to
skip over just the offending notification entry on error.

Reviewed-by: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
Reviewed-by: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Reviewed-by: Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com>
Discussion: https://www.postgresql.org/message-id/fedbd908-4571-4bbe-b48e-63bfdcc38f64@iki.fi
Backpatch-through: 14

Branch
------
REL_17_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/b821c92920f0044d8f4da9ae0dffcb63e3f4ff49

Modified Files
--------------
src/backend/commands/async.c | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Heikki Linnakangas 2025-11-12 19:34:09 pgsql: Clear 'xid' in dummy async notify entries written to fill up pag
Previous Message Daniel Gustafsson 2025-11-12 16:06:25 pgsql: doc: Document effects of ownership change on privileges