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: Heikki Linnakangas <hlinnaka@iki.fi>,
Pavel Stehule <pavel.stehule@gmail.com>,
Onder Kalaci <onder@citusdata.com>,
PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-08-12T22:53:00Z
Lists: pgsql-hackers
Attachments
- 0001-Refactor-backend-signalling-code-v14.patch (application/octet-stream) patch v14-0001
- 0002-Support-optional-message-in-backend-cancel-terminate-v14.patch (application/octet-stream) patch v14-0002
> On 12 Aug 2018, at 11:01, Andres Freund <andres@anarazel.de> wrote: > > On August 12, 2018 12:17:59 AM GMT+02:00, Daniel Gustafsson <daniel@yesql.se> wrote: >>> On 6 Aug 2018, at 09:47, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >>> >>> Has there been any consideration to encodings? >> >> Thats a good point, no =/ >> >>> What happens if the message contains non-ASCII characters, and the >> sending backend is connected to database that uses a different encoding >> than the backend being signaled? >> >> In the current state of the patch, instead of the message you get: >> >> FATAL: character with byte sequence 0xe3 0x82 0xbd in encoding "UTF8" >> has >> no equivalent in encoding “ISO_8859_5" >> >> Thats clearly not good enough, but I’m not entirely sure what would be >> the best >> way forward. Restrict messages to only be in SQL_ASCII? Store the >> encoding of >> the message and check the encoding of the receiving backend before >> issuing it >> for a valid conversion, falling back to no message in case there is >> none? >> Neither seems terribly appealing, do you have any better suggestions? > > Restricting to ASCII seems reasonable. It’s quite restrictive, but it’s the safe option. I’ve hacked this into the updated patch, but kept the backend_feedback() function using pg_mbstrlen() at least for now since it seems the safe option should this be relaxed at some point. Also added a small test by copying text from a ja.po file in the tree. > But note that sqlascii isn't that (it's essentially just arbitrary null terminated data). Easier to relax later. Yeah, my fingers and brain were not in sync during typing, I meant to say ASCII there. I blame a lack of coffee. 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