Re: pg_multixact not getting truncated

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_multixact not getting truncated
Date: 2014-11-21 18:44:50
Message-ID: 546F8822.6070102@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-11-21 18:51:40 Re: pg_multixact not getting truncated
Previous Message Jeff Janes 2014-11-21 18:38:27 Re: Yet another abort-early plan disaster on 9.3