Daniel Gustafsson <daniel@yesql.se> writes:
>> On 24 Aug 2021, at 15:40, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
>> Thanks for looking into this. With your patch applied, tests 2, 3, and 4 fail. Do they pass for you?
> Thats odd, all tests pass for me. Did the logs give an indication as to what
> was failing?
I also tried the patch. It passes for me on my Linux box, although
it takes noticeably longer than before which doesn't seem great.
On wrasse's host, it fails. The Perl log shows:
ok 1 - PPID timer expired
ok 2 - psql was signaled
not ok 3 - query was canceled
# Failed test 'query was canceled'
# at t/020_cancel.pl line 50.
# 'postgres=# SELECT pg_sleep(15);
# Cancel request sent
# '
# doesn't match '(?-xism:canceling statement due to user request)'
ok 4 - Sleep query timer expired
The postmaster log shows that the cancel was received and acted on:
2021-08-24 17:39:39.021 CEST [2178] LOG: database system is ready to accept connections
2021-08-24 17:39:39.270 CEST [2187] 020_cancel.pl LOG: statement: SELECT pg_sleep(15);
2021-08-24 17:39:42.407 CEST [2187] 020_cancel.pl ERROR: canceling statement due to user request
2021-08-24 17:39:42.407 CEST [2187] 020_cancel.pl STATEMENT: SELECT pg_sleep(15);
2021-08-24 17:39:42.426 CEST [2178] LOG: received fast shutdown request
so I'm not sure why the error message didn't make its way back to the
client. Lack of pumping maybe? It's notable that there's not a lot
of time elapsed between the cancel and the shutdown, according to the
postmaster log, which says that we didn't wait for a timeout there.
Anyway, I'm not terribly thrilled with the patch as-presented, because
what I was hoping for was a test free of timing assumptions. This seems
to be worse not better by that light.
regards, tom lane