Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: Additional message in pg_terminate_backend
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: <064E214D-D86F-4917-A0B6-67EAD6BCB24A@yandex-team.ru>
Date: Wed, 17 Dec 2025 16:34:09 +0500
Cc: pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <288F67CA-E019-40B6-892F-54B5D000C18D@yandex-team.ru>
References: <064E214D-D86F-4917-A0B6-67EAD6BCB24A@yandex-team.ru>
To: Roman Khapov <rkhapov@yandex-team.ru>
Archived-At: 
 <https://www.postgresql.org/message-id/288F67CA-E019-40B6-892F-54B5D000C18D%40yandex-team.ru>
Precedence: bulk


> On 13 Dec 2025, at 12:44, Roman Khapov <rkhapov@yandex-team.ru> wrote:
>=20
> Recently I started working on patch for adding additional message from =
admin=20
> in pg_terminate_backend for one of our greenplum fork. The main idea =
is that there must be=20
> done little investigation every time you see 'FATAL:  terminating =
connection due to administrator command=E2=80=99 to understand the =
reason, especially in cases where connection was terminated by another
> user. So it was decided to create some new functions, that allows to =
terminate connection with
> additional message.

Overall idea seems good to me.
Keep in mind that Postgres literals are translated into many languages. =
So text ought to be clear enough for translators to build a sentence =
that precedes termination reason.

>=20
> I did POC patches with the next main ideas:
> - lets add termReasonStr field in every PGPROC, that field can be used =
in ProcessInterrupts()=20
> - implementation of pg_terminate_backend/pg_cancel_backend should be =
accessible from extensions, so lets move it in =
pg_terminate_backend_impl/pg_cancel_backend_impl and add definitions for =
it somewhere
> - write simple extensions, which defines functions like =
pg_terminate_backend_msg, that sets termReasonStr and calls =
pg_terminate_backend_impl

First thing that we need to do is to agree on API of the new feature. We =
do not need core-extension separation for this.
My vote would be for having pg_cancel_backend(reason =
text)\pg_terminate_backend(reason text) along with parameterless =
versions.
32 bytes per PGPROC seems reasonable for a "reason". The patch doesn't =
seem to take care of cleaning "termReasonStr". Is it done elsewhere?
We have a race condition if many backends cancel same backend. Won't =
they mess each other's reason?

Thanks!


Best regards, Andrey Borodin.