Обсуждение: 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 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 .... Thanks, I'll look into the DNS angle - that certainly seems like a possibility. Thanks, again. - DAP
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 >"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 >
"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