Re: [bug fix] "pg_ctl stop" times out when it should respond quickly - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [bug fix] "pg_ctl stop" times out when it should respond quickly
Date
Msg-id CAB7nPqRKSCfj9dYpCgGfNqaRXYXNi9RhRJOrP62bVyAAmtXXAQ@mail.gmail.com
Whole thread Raw
In response to Re: [bug fix] "pg_ctl stop" times out when it should respond quickly  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, Feb 18, 2014 at 1:29 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> MauMau escribió:
> 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.
This might not be worth the trouble for this bug, but actually it
could be useful to many third-part tools and extensions to have a
common and generic way to do things. I have seen many utilities using
a copy/paste of pg_ctl functions and still maintain some of them...
Regards,
--
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Description for pg_replslot in docs
Next
From: Shigeru Hanada
Date:
Subject: Re: inherit support for foreign tables