On Jan 26, 2013 6:56 PM, "Craig Ringer" <cr...@2ndquadrant.com> wrote: > > 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. >
Maybe something to add to pg_ctl? > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
