As a work-around, you can use the scripts at
http://cvs.distributed.net/viewcvs.cgi/stats-sql/tools/
On Thu, Sep 22, 2005 at 02:16:58PM -0400, Jonathan Beit-Aharon wrote:
>
> Hi,
> I'm not a member of this list, so please CC me on responses and
> discussion.
> After a system crash PostgreSQL startup is slow as the database
> recovers. So the db_connect() call from pg_autovacuum terminates as
> soon as it tries to connect to "template1".
> Looking at the README file, I find this note:
> pg_autovacuum does not get started automatically by either the
> postmaster or by pg_ctl. Similarly, when the postmaster exits,
> no one
> tells pg_autovacuum. The result of that is that at the start of
> the
> next loop, pg_autovacuum will fail to connect to the server and
> exit(). Any time it fails to connect pg_autovacuum exit()s.
> So the failure we're experiencing is an unintended result of an
> intended solution. Any suggestions on how I can work-around this
> problem?
> Would it make sense to put the first db_connect() call in the
> init_db_list() routine inside a [configurable repeatition] loop,
> sleeping after disappointed attempt to connect, and breaking out on
> success? That way, I think, when pg_autovacuum is initiated, we
> assume the postmaster is up, but when the VacuumLoop connection
> fails, we assume the postmaster went away, and take our exit().
> Thanks,
> Jonathan
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461