Re: interrupted tap tests leave postgres instances around - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: interrupted tap tests leave postgres instances around
Date
Msg-id cdbd6fa7-e2b6-caa8-3f57-74f954765893@enterprisedb.com
Whole thread Raw
In response to interrupted tap tests leave postgres instances around  (Andres Freund <andres@anarazel.de>)
Responses Re: interrupted tap tests leave postgres instances around  (Andres Freund <andres@anarazel.de>)
List 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.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: log_heap_visible(): remove unused parameter and update comment
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file)