startup time
We have a script process that needs to start a database, execute some
SQL statements, then stop the database. This is done as part of an
application reset, in which we are clearing out database data as part of
the process. This is with 7.4.5 on Solaris 9/intel.
The problem we are having is that in a customer installation, the
startup on the database is taking significantly longer than we have ever
seen it take before. The script needs to be fixed because it has a
hard-coded wait interval value (looping over a "pg_ctl status"), and
it's not stopping properly, so we end up trying to make a connection
before the database is up, getting the "FATAL: database is starting up"
error.
But what I'm curious about is what set of things have to happen between
startup and the server being ready to accept requests. This happens on a
fresh install, so I don't *think* it should be recovery processing. It's
difficult to diagnose because I don't have access to the installation.
If somebody could point me to the area of code that handles startup, a
link to documentation, and/or a bullet list of things that get done in
this startup window, it would give me a starting point for asking
questions of our field people about the installation environment.
Thanks.
- DAP
------------------------------------------------------------------------
----------
David Parker Tazz Networks (401) 709-5130
"David Parker" <dparker@tazznetworks.com> writes:
The problem we are having is that in a customer installation, the
startup on the database is taking significantly longer than we have ever
seen it take before.
Are we talking seconds, minutes, hours, days?
But what I'm curious about is what set of things have to happen between
startup and the server being ready to accept requests. This happens on a
fresh install, so I don't *think* it should be recovery processing.
If it's not doing recovery then the Postgres time proper should be
no more than a second or so, in my experience. Look for
outside-the-database factors. One possibility is a broken DNS
configuration leading to long delays in trying to resolve socket
addresses and such. I've never seen such a problem causing a delay
over a minute though ....
regards, tom lane
The problem we are having is that in a customer installation, the
startup on the database is taking significantly longer than we have
ever seen it take before.Are we talking seconds, minutes, hours, days?
It's in the seconds range, I think, probably not more than a minute, but
I don't have access to specific times from the installation. The root
problem is that our script is not flexible enough, so that needs to
change - I just wanted to get an idea of what "normal" startup times I
should expect.
But what I'm curious about is what set of things have to happen
between startup and the server being ready to accept requests. This
happens on a fresh install, so I don't *think* it should berecovery processing.
If it's not doing recovery then the Postgres time proper
should be no more than a second or so, in my experience. Look
for outside-the-database factors. One possibility is a broken
DNS configuration leading to long delays in trying to resolve
socket addresses and such. I've never seen such a problem
causing a delay over a minute though ....
Thanks, I'll look into the DNS angle - that certainly seems like a
possibility.
Thanks, again.
- DAP
Import Notes
Resolved by subject fallback
Does pg_ctl status return true even if the database is not ready yet to
receive requests? We are using pg_ctl status to tell us if the database
is up, but I'm wondering if it could return true, but a client could
connect and still get the "FATAL: database is starting up" error?
- DAP
Show quoted text
"David Parker" <dparker@tazznetworks.com> writes:
The problem we are having is that in a customer installation, the
startup on the database is taking significantly longer than we have
ever seen it take before.Are we talking seconds, minutes, hours, days?
But what I'm curious about is what set of things have to happen
between startup and the server being ready to accept requests. This
happens on a fresh install, so I don't *think* it should berecovery processing.
If it's not doing recovery then the Postgres time proper
should be no more than a second or so, in my experience. Look
for outside-the-database factors. One possibility is a broken
DNS configuration leading to long delays in trying to resolve
socket addresses and such. I've never seen such a problem
causing a delay over a minute though ....regards, tom lane
Import Notes
Resolved by subject fallback
"David Parker" <dparker@tazznetworks.com> writes:
Does pg_ctl status return true even if the database is not ready yet to
receive requests?
pg_ctl status just checks that the postmaster process is present.
(Until very recently, it wasn't even a bulletproof test for that...)
regards, tom lane