Re: [HACKERS] Per-table freeze limit proposal

On Mon, 2005-11-14 at 23:40 -0300, Alvaro Herrera wrote:

> The whole thing is pretty fragile is somebody manually updates a
> catalog.  But we tell people not to do that, so it should be their
> fault, right?

Hmmmm...sounds scary. Cool ideas in the patch though.

> I discovered one problem with the whole approach.  Per this patch, we
> only store normal Xids in relminxid/relvacuumxid.  So if a table is
> completely frozen, we will store RecentXmin.  We do this because it
> would actually be unsafe to store, say, FrozenXid: if another
> transaction stores/changes a tuple while we are vacuuming it, the Frozen
> mark wouldn't be correct and thus the table could be corrupted if a Xid
> wraparound happens (which is why we use RecentXmin in the first place:
> to cope with the possibility of someone else using the table during the
> vacuum.)

Yep. And because VACUUM FULL FREEZE is no longer possible.

> The problem comes when this is done to template1, and it is copied to
> another database after some millions of transactions have come and go --
> it will seem like the database has suffered wraparound.  We would need
> to vacuum it completely after copied for the stats to be accurate.

I don't understand the issue, can you explain more? I see no problem. If
an identical copy gives a problem then surely template1 should also.

> I'm not sure what to do about that.  I think storing FrozenXid may not
> actually be a totally bad idea.  Comments?

Its not a totally bad idea, but it has some risk, which where
transactions are concerned is not really acceptable.

Perhaps we should reinstate VACUUM FULL FREEZE to do just a FREEZE with
a table lock and skip all that moving data around.

Best Regards, Simon Riggs