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

<font size="+1">Hi,<br /> I'm not a member of this list, so please CC me on responses and discussion.<br /><br /> After
asystem crash PostgreSQL startup is slow as the database </font><font size="+1">recovers.  So the db_connect() call
frompg_autovacuum </font><font size="+1">terminates</font><font size="+1"> as soon as it tries to connect to
"template1".<br/><br /> Looking at the README file, I find this note:<br /></font><font size="+1">    pg_autovacuum
doesnot get started automatically by either the<br />     postmaster or by pg_ctl.  Similarly, when the postmaster
exits,no one<br />     tells pg_autovacuum.  The result of that is that at the start of the<br />     next loop,
pg_autovacuumwill fail to connect to the server and<br />     exit().  Any time it fails to connect pg_autovacuum
exit()s.<br/><br /> So the failure we're experiencing is an unintended result of an intended solution.   Any
suggestionson how I can work-around this problem?<br /><br /> Would it make sense to put the first db_connect() call in
theinit_db_list() routine inside a [configurable repeatition] loop, sleeping after disappointed attempt to connect, and
breakingout on success?   That way, I think, when pg_autovacuum is initiated, we assume the postmaster is up, but when
theVacuumLoop connection fails, we assume the postmaster went away, and take our exit().<br /><br /> Thanks,<br />
Jonathan<br/><br /></font> 

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