On 2022-10-19 17:38:50 +0200, Alvaro Herrera wrote:
> Pushed this. It should improve things significantly.
Thanks for working on this!
Pushed this. It should improve things significantly.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"
On 2022-Oct-01, Andres Freund wrote:
> Perhaps the END{} routine should call $node->_update_pid(-1); if $exit_code !=
> 0 and _pid is undefined?
Yeah, that sounds reasonable.
> That does seem to reduce the incidence of "leftover" postgres
> instances. 001_start_stop.pl leaves some behind, but th
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 starte
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 po
Hi,
On 2022-09-30 11:17:00 +0200, Alvaro Herrera wrote:
> But on testing, some nodes linger after being sent a shutdown signal.
> I'm not clear why this is -- I think it's due to the fact that we send
> the signal just as the node is starting up, which means the signal
> doesn't reach the process.
On 2022-Sep-30, Michael Paquier wrote:
> On Thu, Sep 29, 2022 at 09:07:34PM -0700, Andres Freund wrote:
> > ISTM we should at least install a SIGINT/TERM handler in Cluster.pm that
> > does
> > the stuff we already do in END.
>
> Hmm, indeed. And here I thought that END was actually taking care
On Thu, Sep 29, 2022 at 09:07:34PM -0700, Andres Freund wrote:
> ISTM we should at least install a SIGINT/TERM handler in Cluster.pm that does
> the stuff we already do in END.
Hmm, indeed. And here I thought that END was actually taking care of
that on an interrupt..
--
Michael
signature.asc
D
Hi,
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
la
