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
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 |
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 |