Re: Disappearing Records

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: John Sidney-Woollett <johnsw(at)wardbrook(dot)com>, Venki <Venki(at)insoft(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Disappearing Records
Date: 2005-11-02 15:28:56
Message-ID: 5801.1130945336@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Martijn van Oosterhout <kleptog(at)svana(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-11-02 16:18:03 Re: Disappearing Records
Previous Message Steve Wampler 2005-11-02 15:00:34 Re: Postgres + CentOS