Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Per-table freeze limit proposal

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Per-table freeze limit proposal
Date: 2005-11-15 22:36:33
Message-ID: 1132094193.3388.95.camel@holly (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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




In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-11-15 23:09:03
Subject: Re: someone working to add merge?
Previous:From: Simon RiggsDate: 2005-11-15 22:11:34
Subject: Re: MERGE vs REPLACE

pgsql-patches by date

Next:From: Philip YarraDate: 2005-11-15 22:59:04
Subject: pl/pgSQL doco patch
Previous:From: Andreas SeltenreichDate: 2005-11-15 16:33:06
Subject: Re: TODO item -- Improve psql's handling of multi-line queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group