Re: pg_clog & vacuum oddness - Mailing list pgsql-admin

From DHS Webmaster
Subject Re: pg_clog & vacuum oddness
Date
Msg-id 3F9FF092.5849E470@dhs-club.com
Whole thread Raw
In response to pg_clog & vacuum oddness  (Jeff <threshar@torgo.978.org>)
Responses Re: pg_clog & vacuum oddness  (Jeff <threshar@torgo.978.org>)
Re: pg_clog & vacuum oddness  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
This thread caught my eye and I decided to look at our pg_clog
directory. Sure enough we have got every clog file since we upgraded
back in April, 0000 - 02F8.
We vacuum our working database nightly. Although this is not a 'full',
we don't exclude any tables. We don't do anything with template1
(knowingly), so we do not perform any maintenance on it either.
Questions:
1. Should we be doing a periodic vacuum on template1?
2. Is what I am seeing possibly indicative of something else beside
template1 that would show up the postgres log.
3. It is safe to delete all the clog files prior to the last restart of
postgres, yes?

Tom Lane wrote:
>
> Jeff <threshar@torgo.978.org> writes:
> > [ pg_clog not getting truncated ]
>
> pg_clog is truncated on the basis of the oldest completely vacuumed
> database in your installation.  Most likely your maintenance script
> is failing to vacuum some database(s) (template1, perhaps?) and/or
> is doing table-by-table vacuums rather than an unqualified VACUUM.
>
> I doubt this explains any performance problems though.  Old pg_clog
> segments don't do anything except sit there.
>
>                         regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match

--
Bill MacArthur
Webmaster
DHS Club

pgsql-admin by date:

Previous
From: Jeff
Date:
Subject: Re: pg_clog & vacuum oddness
Next
From: Jeff
Date:
Subject: Re: pg_clog & vacuum oddness