Re: [HACKERS] pg_ctl configurable timeout
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Alvaro Herrera <[EMAIL PROTECTED]> writes: >>> I think the mythical pg_ping utility should be written. It seems the >>> easiest way out of the problem. >> >> If pg_ctl were still a shell script there would be some point in that, >> but since it's a C program it can certainly do anything a separate >> utility would do. > Well, pg_ctl would not be the only user of such an utility. Things like > (say) control panels for shared hosting could benefit from it as well. > As would system health monitors. I still see no point in creating a separate binary for the functionality. If you want to make it available to shell scripts, invent a "pg_ctl ping" subcommand. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pg_ctl configurable timeout
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I think the mythical pg_ping utility should be written. It seems the > > easiest way out of the problem. > > If pg_ctl were still a shell script there would be some point in that, > but since it's a C program it can certainly do anything a separate > utility would do. Well, pg_ctl would not be the only user of such an utility. Things like (say) control panels for shared hosting could benefit from it as well. As would system health monitors. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_ctl configurable timeout
On Mon, 2007-10-29 at 17:34 -0300, Alvaro Herrera wrote: > Maybe hack the postmaster to have a new special connection mode which > keeps the connection open until the startup process exits, to avoid > polling continuously (ideally report progress too, if at all > possible). That sounds good to me. The spurious connection messages look weird and its difficult to say that's one of the ERRORs that isn't an error. There has to be a way for pg_ctl to ask whether the server is still starting up without causing a message every second in the server log. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_ctl configurable timeout
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I think the mythical pg_ping utility should be written. It seems the > easiest way out of the problem. If pg_ctl were still a shell script there would be some point in that, but since it's a C program it can certainly do anything a separate utility would do. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_ctl configurable timeout
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: >> How about an environment variable to control the timeout? Is that >> cleaner? > I don't see why it should be. I think Peter's --timeout suggestion > should be just fine. I wrote a moment ago that the user can hit control-C when he gets bored, but that argument only works for interactive use of pg_ctl. In a script I think you'd want a --timeout option. I don't see the advantage of an environment variable in either scenario. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_ctl configurable timeout
Peter Eisentraut wrote: > Am Freitag, 17. August 2007 schrieb Peter Eisentraut: > > I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl > > sometimes just times out and there is no way to make it wait a little > > longer. I would like to add an option to be able to change that, say > > pg_ctl -w --timeout=120. Comments? > > Lost track of this, but it keeps biting me. > > Somehow, the 60 second timeout seems completely arbitrary anyway. Maybe we > should remove it altogether. We could add an option as described above, but > then the packager who creates the init script or whoever creates the initial > configuration will have to make an equally arbitrary choice. And most likely > you will not notice that your configuration is insufficient until you are > really in a bind. > > What should we do? I think the mythical pg_ping utility should be written. It seems the easiest way out of the problem. Maybe hack the postmaster to have a new special connection mode which keeps the connection open until the startup process exits, to avoid polling continuously (ideally report progress too, if at all possible). -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J Y dijo Dios: "Que sea Satanás, para que la gente no me culpe de todo a mÃ." "Y que hayan abogados, para que la gente no culpe de todo a Satanás" ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_ctl configurable timeout
Bruce Momjian wrote: How about an environment variable to control the timeout? Is that cleaner? I don't see why it should be. I think Peter's --timeout suggestion should be just fine. cheers andrtew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_ctl configurable timeout
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Somehow, the 60 second timeout seems completely arbitrary anyway. Maybe we > should remove it altogether. We could add an option as described above, but > then the packager who creates the init script or whoever creates the initial > configuration will have to make an equally arbitrary choice. Yeah. One problem is that we use the same timeout for startup and shutdown, which really are entirely different; and the other problem is that we've not wanted pg_ctl to have too many smarts about the server's internal behavior. On startup, it would be reasonable to assume failure if we don't see a postmaster pid-file appear PDQ, but then after that it might stay in the "database is starting up" state for a long time (maybe even indefinitely if it's a warm standby server). Still, you could argue that it's reasonable to keep waiting as long as the postmaster keeps returning "database is starting up" when pinged. On shutdown, it'd be reasonable to expect that the postmaster starts returning "database is shutting down" almost immediately, and to report failure if not. However, if it was a default "smart mode" stop you could again wait indefinitely for clients to decide to give up their sessions. I'm not sure if it's sane for pg_ctl to wait indefinitely in that scenario. I agree that just pushing the choice of timeout onto the user's shoulders wouldn't be much of an improvement. He can always hit ^C if he gets tired of waiting. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_ctl configurable timeout
Peter Eisentraut wrote: > Am Freitag, 17. August 2007 schrieb Peter Eisentraut: > > I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl > > sometimes just times out and there is no way to make it wait a little > > longer. I would like to add an option to be able to change that, say > > pg_ctl -w --timeout=120. Comments? > > Lost track of this, but it keeps biting me. > > Somehow, the 60 second timeout seems completely arbitrary anyway. Maybe we > should remove it altogether. We could add an option as described above, but > then the packager who creates the init script or whoever creates the initial > configuration will have to make an equally arbitrary choice. And most likely > you will not notice that your configuration is insufficient until you are > really in a bind. > > What should we do? How about an environment variable to control the timeout? Is that cleaner? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_ctl configurable timeout
> --- Original Message --- > From: Peter Eisentraut <[EMAIL PROTECTED]> > To: pgsql-hackers@postgresql.org > Sent: 29/10/07, 17:54:00 > Subject: Re: [HACKERS] pg_ctl configurable timeout > > Am Freitag, 17. August 2007 schrieb Peter Eisentraut: > > I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl > > sometimes just times out and there is no way to make it wait a little > > longer. I would like to add an option to be able to change that, say > > pg_ctl -w --timeout=120. Comments? > > Lost track of this, but it keeps biting me. > > Somehow, the 60 second timeout seems completely arbitrary anyway. Maybe we > should remove it altogether. We could add an option as described above, but > then the packager who creates the init script or whoever creates the initial > configuration will have to make an equally arbitrary choice. And most likely > you will not notice that your configuration is insufficient until you are > really in a bind. > > What should we do? We need the option on Windows to prevent dependent services being started too quickly. The same problem occurs there with pg_ctl reporting it's status to the service control manager. The scm interface handles this by having the service regularly increment a variable, and if required, updating the estimated startup time. A similar architecture might be feasible if we had the postmaster signal pg_ctl periodically until started at which point a different signal is sent. We then only timeout if no pulse or started signal is received within X seconds. Regards, Dave ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pg_ctl configurable timeout
Am Freitag, 17. August 2007 schrieb Peter Eisentraut: > I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl > sometimes just times out and there is no way to make it wait a little > longer. I would like to add an option to be able to change that, say > pg_ctl -w --timeout=120. Comments? Lost track of this, but it keeps biting me. Somehow, the 60 second timeout seems completely arbitrary anyway. Maybe we should remove it altogether. We could add an option as described above, but then the packager who creates the init script or whoever creates the initial configuration will have to make an equally arbitrary choice. And most likely you will not notice that your configuration is insufficient until you are really in a bind. What should we do? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_ctl configurable timeout
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zdenek Kotala wrote: Peter Eisentraut wrote: I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl sometimes just times out and there is no way to make it wait a little longer. I would like to add an option to be able to change that, say pg_ctl -w --timeout=120. Comments? +1 I played with 2GB shared buffers and stop action takes 10-20s. On system with more memory 60s is not enough. Huh? I have never seen this problem. It happened when I stop server after heavy performance test. I expected that postgres tries to check if there is not some dirty page in the buffer, but I did not investigate in it. Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pg_ctl configurable timeout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zdenek Kotala wrote: > Peter Eisentraut wrote: >> I'm having trouble with the hardcoded 60 second timeout in pg_ctl. >> pg_ctl sometimes just times out and there is no way to make it wait a >> little longer. I would like to add an option to be able to change >> that, say pg_ctl -w --timeout=120. Comments? > > +1 > > I played with 2GB shared buffers and stop action takes 10-20s. On system > with more memory 60s is not enough. Huh? I have never seen this problem. Joshua D. Drake > > > Zdenek > > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGze9uATb/zqfZUUQRAsjDAJwI2Q3Cv8cCIqmNXnbbw1vQLXDADwCdHBdx fWqe0ffSciAfAcdIN3jXMfw= =m+9v -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_ctl configurable timeout
Peter Eisentraut wrote: I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl sometimes just times out and there is no way to make it wait a little longer. I would like to add an option to be able to change that, say pg_ctl -w --timeout=120. Comments? +1 I played with 2GB shared buffers and stop action takes 10-20s. On system with more memory 60s is not enough. Zdenek ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly