Re: interrupted tap tests leave postgres instances around
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2022-10-04T08:24:19Z
Lists: pgsql-hackers
On 30.09.22 06:07, Andres Freund wrote: > When tap tests are interrupted (e.g. with ctrl-c), we don't cancel running > postgres instances etc. That doesn't strike me as a good thing. > > In contrast, the postgres instances started by pg_regress do terminate. I > assume this is because pg_regress starts postgres directly, whereas tap tests > largely start postgres via pg_ctl. pg_ctl will, as it should, start postgres > without a controlling terminal. Thus a ctrl-c won't be delivered to it. I ran into the problem recently that pg_upgrade starts the servers with pg_ctl, and thus without terminal, and so you can't get any password prompts for SSL keys, for example. Taking out the setsid() call in pg_ctl.c fixed that. I suspect this is ultimately the same problem. We could make TAP tests and pg_upgrade not use pg_ctl and start postmaster directly. I'm not sure how much work that would be, but seeing that pg_regress does it, it doesn't seem unreasonable. Alternatively, perhaps we could make a mode for pg_ctl that it doesn't call setsid(). This could be activated by an environment variable. That might address all these problems, too.
Commits
-
Better handle interrupting TAP tests
- 460c0076e8de 16.0 landed