Re: pg_autovacuum crashes when query fails for temp tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jeff Boes <jboes(at)nexcerpt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_autovacuum crashes when query fails for temp tables
Date: 2004-04-21 04:38:52
Message-ID: 26127.1082522332@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> System Tables: pg_autovacuum treats non-shared system tables just like
> any other table. It monitors the activity and vacuums when it deems it
> appropriate. As for shared system tables: In user databases they are
> only analyzed by pg_autovacuum, while connected to template1,
> pg_autovacuum will treat the shared tables as normal tables and vacuum
> when appropriate.

As long as you hit template1 reasonably often, this will work. But I'm
a bit concerned about the possibility that some maverick will decide he
doesn't need template1. (It's at least theoretically possible to run
without it.)

Plan B would be to ignore the sharedness issue and vacuum/analyze shared
catalogs the same as anything else. While this would certainly result
in more vacuums than really necessary, these tables are probably small
enough that it'd hardly matter ...

Comments?

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message mike g 2004-04-21 04:48:49 Duplicate variable declared?
Previous Message Christopher Kings-Lynne 2004-04-21 04:05:26 Re: pg_autovacuum crashes when query fails for temp tables

Browse pgsql-hackers by date

  From Date Subject
Next Message mike g 2004-04-21 04:48:49 Duplicate variable declared?
Previous Message vinayj 2004-04-21 04:13:33 Is there any method to keep table in memory at startup