Re: pg_multixact not getting truncated - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: pg_multixact not getting truncated
Date
Msg-id 546F8822.6070102@agliodbs.com
Whole thread Raw
In response to Re: pg_multixact not getting truncated  (Josh Berkus <josh@agliodbs.com>)
Responses Re: pg_multixact not getting truncated  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Greg,


> This is actually the way it used to be. It was changed because it was
> discovered there was some case where an unfrozen xid would end up in
> template0 anyways and for some reason it was hard to be sure to avoid it. I
> don't recall exactly what the situation was that triggered it but the
> argument was made then that it was safest to just include template0 in
> autovacuum rather than depend on getting this 100% right and risk
> corruption.

Right, and that was fine before pg_multixact, because even with 500m
XIDs in the bank, pg_clog is still pretty small.  The problem is that
with the same number of multixacts, pg_multixact is around *16GB* in size.

Thing is, template0 is just there as a check on users messing up
template1.  Having that kind if precaution causing repeated operational
problems for users is not good design.  Maybe we should just get rid of
template0 and come up with some other mechanism to reset template1 to
bare-bones state.

Actually, here's a question ... pg_clog is usually smaller than I think
it should be (that is, smaller than 4bytes * XID_age).  Why is that?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Automatic PG_PRINTF_ATTRIBUTE
Next
From: Josh Berkus
Date:
Subject: Re: pg_multixact not getting truncated