Luis Menina <lmenina@anevia.com> writes:
> I've been trying to run some pg_ctl command inside a python script,
> and saw that some of them where deadlocking. It seems that the
> commands that start postgres handle stdout in a way that that block
> the caller. Redirecting stdout to /dev/null or to a file using the -l
> option allow me to workaround the problem, but fixing it upstream
> would be nice.
I think this is just pilot error, not a bug. When you launch the
postmaster via pg_ctl and don't supply a -l option, the postmaster's
stdout remains connected to wherever pg_ctl's stdout went to --- which,
in this instance, is a pipe leading to the python script's process.
So even after pg_ctl exits, subprocess.check_output() sees the pipe as
still having live writers, and it keeps waiting for more input (which
may indeed be forthcoming, if the postmaster prints log data to stdout).
You can verify this by issuing "pg_ctl stop" from another terminal
and noting that the python script exits when the postmaster shuts down.
This can actually be useful behavior; for instance you might want to
collect the postmaster's stdout via a python script. So we are certainly
not going to call it a bug and break it. What's perhaps more debatable is
whether it should be the default ... but it's been that way for a decade
or two, so changing the default would probably annoy far more people than
it would help.
regards, tom lane
