Re: Disappearing Records - Mailing list pgsql-general

From Tom Lane
Subject Re: Disappearing Records
Date
Msg-id 5801.1130945336@sss.pgh.pa.us
Whole thread Raw
In response to Re: Disappearing Records  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Disappearing Records  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Wed, Nov 02, 2005 at 09:46:38AM -0500, Tom Lane wrote:
>> You sure about that?  I think VACUUM just tests for "committed or not".
>>
>> I'm too lazy to set up a test case, but it's possible that VACUUM FREEZE
>> would resurrect wrapped-around tuples, or could be made to with only a
>> small code tweak.

> Well, that would be really nice to be able to tell people. But looking
> at the code of HeapTupleSatisfiesVacuum it spends a lot of time
> checking hint bits. While we might be able to fiddle the one function,
> checking all the places involving the hint bits could be nasty. Or not.

You're missing the forest for the trees.  The hint bits don't do
anything except save a visit to pg_clog.  It's still going to come back
with HEAPTUPLE_LIVE.  The question is whether VACUUM can or should be
tweaked to substitute FrozenTransactionId when the xmin is "in the
future".

Looking at the code, I think that actually a regular, non-FREEZE VACUUM
would do the "right thing" for tuples up to about 1 billion xacts past
wrap, which is probably enough.  So the answer may be "just VACUUM".
I'm still too lazy to test it though.

            regards, tom lane

pgsql-general by date:

Previous
From: Steve Wampler
Date:
Subject: Re: Postgres + CentOS
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Disappearing Records