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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
