MauMau escribió: > pg_ctl timed out waiting for the zombie postgres. > > maumau 19621 18849 0 15:21 pts/9 00:00:00 [postgres] <defunct> > maumau 20253 18849 0 15:22 pts/9 00:00:00 > /maumau/postgresql-9.4/src/test/regress/./tmp_check/install//maumau/pgsql/bin/pg_ctl > stop -D /maumau/postgresql-9.4/src/test/regress/./tmp_check/data -s > -m fast > > pg_regress must wait for postgres to terminate by calling waitpid(), > because it invoked postgres directly. The attached > pg_regress_pg_stop.patch does this. If you like the combination of > this and the original fix for pg_ctl in one patch, please use > pg_stop_fail_v3.patch.
The pg_regress part is ugly. However, pg_regress is doing something unusual when starting postmaster itself, so the ugly coding to stop it seems to match. If we wanted to avoid the ugliness here, the right fix would be to use pg_ctl to start postmaster as well as to stop it. But that'd come at a price, because we would need more ugly code to figure out postmaster's PID. All in all, the compromise proposed by this patch seems acceptable. If we really wanted to make all this real pretty, we could provide a "libpg_ctl" library to start and stop postmaster, as well as query the PID. Probably not worth the trouble. I would apply this patch to all supported branches after this week's release. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers