Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)

On 01/27/2013 06:20 AM, Phil Sorber wrote:
> On Sat, Jan 26, 2013 at 4:37 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2013/1/26 Phil Sorber <phil(at)omniti(dot)com>:
>>> On Sat, Jan 26, 2013 at 12:39 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>> 2013/1/26 Phil Sorber <phil(at)omniti(dot)com>:
>>>>> On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>>>> 2013/1/26 Phil Sorber <phil(at)omniti(dot)com>:
>>>>>>> On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> We now haw to solve small puppet issue, because our puppets try to
>>>>>>>> start server too early, when old instance live still.
>>>>>>>>
>>>>>>>> Maybe some new parameter - is_done can be useful.
>>>>>>>>
>>>>>>> What about something like:
>>>>>>> pg_isready; while [ $? -ne 2 ]; do sleep 1; pg_isready; done
>>>>>> it is not enough - server is done in a moment, where can be started
>>>>>> again - or when we can do safe copy of database data directory.
>>>>>>
>>>>> I guess i am not completely understanding the case you are trying to
>>>>> solve. Can you explain a bit further?
>>>> We use puppets and due some simplification we cannot to use reload
>>>> when configuration is changed. Our puppets has not enough intelligence
>>>> to understand when is reload enough and when is restart necessary. So
>>>> any change to configuration require restarting postgres. I don't know
>>>> why "service restart" are not used. I believe so our puppet guru know
>>>> it. It just do sequence STOP:START Now puppets are "smart" and able
>>>> to wait for time, when server is ready. But there are missing simple
>>>> test if server is really done and I see a error messages related to
>>>> too early try to start. So some important feature can be verification
>>>> so server is really done.
>>>>
>>>> We can do it with test on pid file now - and probably we will use it.
>>>> But I see so this is similar use case (in opposite direction)
>>>>
>>> I guess I am still not clear why you can't do:
>>>
>>> stop_pg_via_puppet
>>> pg_isready
>>> while [ $? -ne 2 ]
>>> do
>>> sleep 1
>>> pg_isready
>>> done
>>> do_post_stop_things
>>> start_pg_via_puppet
>>>
>> because ! pg_isready <> pg_isdone
>>
> So you are proposing a different utility? Sorry, I thought you were
> proposing a new option to pg_isready. What would pg_isdone be testing
> for specifically? Is this something that would block until it has
> confirmed a shutdown?

That's what it sounds like - confirming that PostgreSQL is really fully
shut down.

I'm not sure how you could do that over a protocol connection, myself.
I'd just read the postmaster pid from the pidfile on disk and then `kill
-0` it in a delay loop until the `kill` command returns failure. This
could be a useful convenience utility but I'm not convinced it should be
added to pg_isready because it requires local and possibly privileged
execution, unlike pg_isready's network based operation. Privileges could
be avoided by using an aliveness test other than `kill -0`, but you
absolutely have to be local to verify that the postmaster has fully
terminated - and it wouldn't make sense for a non-local process to care
about this anyway.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services