Re: [HACKERS] Optional message to user when terminating/cancelling backend - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Optional message to user when terminating/cancelling backend
Date
Msg-id CAB7nPqQUZVWPZvvrdtvLij112tmaA1DLR-3bzZsF9WU3yb3dvA@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Optional message to user when terminating/cancelling backend  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: [HACKERS] Optional message to user when terminating/cancellingbackend
List pgsql-hackers
On Tue, Jun 20, 2017 at 3:24 AM, Daniel Gustafsson <daniel@yesql.se> wrote:
> The message is stored in a new shmem area which is checked when the session is
> aborted.  To keep things simple a small buffer is kept per backend for the
> message.  If deemed too costly, keeping a central buffer from which slabs are
> allocated can be done (but seemed rather complicated for little gain compared
> to the quite moderate memory spend.)

I think that you are right to take the approach with a per-backend
slot. This will avoid complications related to entry removals and
locking issues. There would be scaling issues as well if things get
very signaled for a lot of backends.

+#define MAX_CANCEL_MSG 128
That looks enough.

+           LWLockAcquire(BackendCancelLock, LW_EXCLUSIVE);
+
+           strlcpy(slot->message, message, sizeof(slot->message));
+           slot->len = strlen(message);
Why not using one spin lock per slot and save it in BackendCancelShmemStruct?

+   pid_t       pid = PG_GETARG_INT32(0);
+   char       *msg = text_to_cstring(PG_GETARG_TEXT_PP(1));
+
+   PG_RETURN_BOOL(pg_terminate_backend_internal(pid, msg));
It would be more solid to add some error handling for messages that
are too long, or at least truncate the message if too long.
-- 
Michael



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: [HACKERS] CREATE SUBSCRIPTION log noise
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Getting server crash on Windows when using ICU collation