Re: [HACKERS] Optional message to user when terminating/cancelling backend
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Andres Freund <andres@anarazel.de>,
Onder Kalaci <onder@citusdata.com>,
PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-08-23T18:53:37Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes: > On Wed, Jul 25, 2018 at 7:27 PM, Daniel Gustafsson <daniel@yesql.se> wrote: >> Seems the build of the updated patch built and tested Ok. Still have no idea >> why the previous one didn’t. > That problem apparently didn't go away. cfbot tested it 7 times in > the past week, and it passed only once on Windows: > https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.9691 > The other times all failed like this: > https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.9833 I think this is just a timing problem: the signal gets sent, but it might or might not get received before the current statement ends. It's possible that a signal-sent-to-self can be expected to be received synchronously on all Unix platforms, but I wouldn't entirely bet on that (in particular, the POSIX text for kill(2) does NOT guarantee it); and our Windows signal implementation certainly doesn't guarantee anything of the sort. I don't think there's necessarily anything wrong with the code, but you can't test it with such a simplistic test as this and expect stable results. If you feel an urgent need to have a test case, try building an isolationtester script. regards, tom lane
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