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/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-----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@postgresql.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-----

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

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

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@momjian.us> 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

Peter Eisentraut <peter_e@gmx.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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

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

Andrew Dunstan <andrew@dunslane.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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly