On 01/27/2013 06:20 AM, Phil Sorber wrote: > On Sat, Jan 26, 2013 at 4:37 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: >> 2013/1/26 Phil Sorber <p...@omniti.com>: >>> On Sat, Jan 26, 2013 at 12:39 PM, Pavel Stehule <pavel.steh...@gmail.com> >>> wrote: >>>> 2013/1/26 Phil Sorber <p...@omniti.com>: >>>>> On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule <pavel.steh...@gmail.com> >>>>> wrote: >>>>>> 2013/1/26 Phil Sorber <p...@omniti.com>: >>>>>>> On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule >>>>>>> <pavel.steh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
