Обсуждение: pgsql: Unbreak recovery test on Windows
Unbreak recovery test on Windows On Windows we need to send explicit quit messages to psql or the TAP tests can hang. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/677271a3a125e294b33b891669f594a2c8cb36ce Modified Files -------------- src/test/recovery/t/022_crash_temp_files.pl | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
Andrew Dunstan <andrew@dunslane.net> writes:
> Unbreak recovery test on Windows
Hmm, looks like this broke things on other machines.
crake and sifaka (so far) are showing
# Running: pg_ctl kill KILL 2237831
ok 3 - killed process with KILL
ack Broken pipe: write( 13, '\\q
' ) at /usr/share/perl5/vendor_perl/IPC/Run/IO.pm line 549.
which looks like a race condition: did we manage to stuff the "\q"
command down the pipe before killing the psql process, or not?
regards, tom lane
On 3/21/21 12:38 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Unbreak recovery test on Windows > Hmm, looks like this broke things on other machines. > crake and sifaka (so far) are showing > > # Running: pg_ctl kill KILL 2237831 > ok 3 - killed process with KILL > ack Broken pipe: write( 13, '\\q > ' ) at /usr/share/perl5/vendor_perl/IPC/Run/IO.pm line 549. > > which looks like a race condition: did we manage to stuff the "\q" > command down the pipe before killing the psql process, or not? > > Ugh. Is there any reason we need to do those kills before we end the psql processes? If not I'm tempted just to move them - after the psql's are finished it should be safe. At any rate I'll go and test that. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
On 3/21/21 1:06 PM, Andrew Dunstan wrote: > On 3/21/21 12:38 PM, Tom Lane wrote: >> Andrew Dunstan <andrew@dunslane.net> writes: >>> Unbreak recovery test on Windows >> Hmm, looks like this broke things on other machines. >> crake and sifaka (so far) are showing >> >> # Running: pg_ctl kill KILL 2237831 >> ok 3 - killed process with KILL >> ack Broken pipe: write( 13, '\\q >> ' ) at /usr/share/perl5/vendor_perl/IPC/Run/IO.pm line 549. >> >> which looks like a race condition: did we manage to stuff the "\q" >> command down the pipe before killing the psql process, or not? >> >> > > Ugh. Is there any reason we need to do those kills before we end the > psql processes? If not I'm tempted just to move them - after the psql's > are finished it should be safe. At any rate I'll go and test that. > > Well, no good deed goes unpunished. That makes things hang on my Linux box. Maybe we should just send the \q on Windows. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
> Ugh. Is there any reason we need to do those kills before we end the
> psql processes? If not I'm tempted just to move them - after the psql's
> are finished it should be safe. At any rate I'll go and test that.
IIUC, that'd completely destroy the point of the test, which is to make
sure we clean up when a backend dies unexpectedly. If we allow the
psql's to exit then the backend might be able to complete normal cleanup
before we can SIGKILL it.
Probably the best thing for now is to revert your change and instead
just skip the whole test script on Windows.
regards, tom lane
On 3/21/21 2:16 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Ugh. Is there any reason we need to do those kills before we end the >> psql processes? If not I'm tempted just to move them - after the psql's >> are finished it should be safe. At any rate I'll go and test that. > IIUC, that'd completely destroy the point of the test, which is to make > sure we clean up when a backend dies unexpectedly. If we allow the > psql's to exit then the backend might be able to complete normal cleanup > before we can SIGKILL it. > > Probably the best thing for now is to revert your change and instead > just skip the whole test script on Windows. > > OK, will do that. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com