pg_autovacuum startup from /etc/rc fails after system crash
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#3333ff">
<font size="+1">Hi,<br>
I'm not a member of this list, so please CC me on responses and
discussion.<br>
<br>
After a system crash PostgreSQL startup is slow as the database </font><font
size="+1">recovers. So the db_connect() call from pg_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 does not 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_autovacuum will 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 suggestions on how I can work-around this
problem?<br>
<br>
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().<br>
<br>
Thanks,<br>
Jonathan<br>
<br>
</font>
</body>
</html>
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