Re: pg_ctl configurable timeout

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?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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

-----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 majordomo(at)postgresql(dot)org 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-----

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

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/

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

Peter Eisentraut <peter_e(at)gmx(dot)net> 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

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

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"

Andrew Dunstan <andrew(at)dunslane(dot)net> 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

Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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 Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> 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.

I have implemented pg_ctl -t secs timeout option with the attached
patch. It still defaults to 60. I did not code the 'ping' option.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +