Re: pg_autovacuum startup from /etc/rc fails after system crash

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

In response to

Browse pgsql-hackers by date

  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