Re: pg_clog & vacuum oddness
От | DHS Webmaster |
---|---|
Тема | Re: pg_clog & vacuum oddness |
Дата | |
Msg-id | 3F9FF092.5849E470@dhs-club.com обсуждение исходный текст |
Ответ на | pg_clog & vacuum oddness (Jeff <threshar@torgo.978.org>) |
Ответы |
Re: pg_clog & vacuum oddness
Re: pg_clog & vacuum oddness |
Список | 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 по дате отправления: