|From:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] Optional message to user when terminating/cancelling backend|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On 9 Apr 2018, at 23:55, Andres Freund <andres(at)anarazel(dot)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
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).
|Next Message||Andres Freund||2018-06-13 19:16:21||Re: [HACKERS] Optional message to user when terminating/cancelling backend|
|Previous Message||Andres Freund||2018-06-13 18:53:21||Re: Portability concerns over pq_sendbyte?|