From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Jonathan Beit-Aharon <jbeitaharon(at)intrusic(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_autovacuum startup from /etc/rc fails after system crash |
Date: | 2005-09-26 18:02:49 |
Message-ID: | 20050926180249.GL30974@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-09-26 18:05:44 | Re: \d on database with a lot of tables is slow |
Previous Message | Ron Mayer | 2005-09-26 17:57:54 | Re: On Logging |