From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optional message to user when terminating/cancelling backend |
Date: | 2017-06-21 03:06:33 |
Message-ID: | CAB7nPqQUZVWPZvvrdtvLij112tmaA1DLR-3bzZsF9WU3yb3dvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 20, 2017 at 3:24 AM, Daniel Gustafsson <daniel(at)yesql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-06-21 04:20:36 | Re: Getting server crash on Windows when using ICU collation |
Previous Message | Jeff Janes | 2017-06-21 02:54:03 | CREATE SUBSCRIPTION log noise |