Re: interrupted tap tests leave postgres instances around

Hi,

On 2022-10-04 10:24:19 +0200, Peter Eisentraut wrote:
> 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.

For this specific case I wonder if pg_upgrade should disable ssl... That would
require fixing pg_upgrade to use a unix socket on windows, but that'd be a
good idea anyway.

> 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.

It's not trivial, particularly from perl. Check all the stuff pg_regress and
pg_ctl do around windows accounts and tokens.

> 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.

It looks like that won't help. Because pg_ctl exits after forking postgres,
postgres parent isn't the shell anymore...

Greetings,

Andres Freund