From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: interrupted tap tests leave postgres instances around |
Date: | 2022-10-04 08:24:19 |
Message-ID: | cdbd6fa7-e2b6-caa8-3f57-74f954765893@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-10-04 08:31:12 | Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file) |
Previous Message | Peter Eisentraut | 2022-10-04 08:18:43 | Re: log_heap_visible(): remove unused parameter and update comment |