Re: [HACKERS] Optional message to user when terminating/cancelling backend
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-06-13T18:54:03Z
Lists: pgsql-hackers
Attachments
- 0001-Refactor-backend-signalling-code-v11.patch (application/octet-stream) patch v11-0001
- 0002-Support-optional-message-in-backend-cancel-terminate-v11.patch (application/octet-stream) patch v11-0002
> On 9 Apr 2018, at 23:55, Andres Freund <andres@anarazel.de> wrote: > On 2017-06-20 13:01:35 -0700, Andres Freund wrote: >> For extensions it'd also be useful if it'd be possible to overwrite the >> error code. E.g. for citus there's a distributed deadlock detector, >> running out of process because there's no way to interrupt lock waits >> locally, and we've to do some ugly hacking to generate proper error >> messages and code from another session. > > What happened to this request? Seems we're out of the crunch mode and > could round the feature out a littlebit more… Revisiting old patches, I took a stab at this request. Since I don’t really have a use case for altering the sqlerrcode other than the on that Citus.. cited, I modelled the API around that. The slot now holds a sqlerrcode as well as a message, with functions to just set the message keeping the default sqlerrcode for when that is all one wants to do. There is no function for just altering the sqlerrcode without a message as that seems not useful to me. The combination of sqlerrcode and message was dubbed SignalFeedback for lack of a better term. With this I also addressed something that annoyed me; I had called all the functions Cancel* which technically isn’t true since we also support termination. There are no new user facing changes in patch compared to the previous version. This patchset still has the refactoring that Alvaro brought up upthread. Parking this again the commitfest as it was returned with feedback from the last one it was in (all review comments addressed, see upthread). cheers ./daniel
Commits
-
Refactor user-facing SQL functions signalling backends
- 09921f397b84 12.0 landed
-
Introduce 64-bit hash functions with a 64-bit seed.
- 81c5e46c490e 11.0 cited