Re: logical changeset generation v4 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: logical changeset generation v4
Date
Msg-id CA+TgmoZHs501D-p3gx-rZ56QvLqsJtVstp7d+VpAmMkr5HjS4Q@mail.gmail.com
Whole thread Raw
In response to Re: logical changeset generation v4  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: logical changeset generation v4
Re: logical changeset generation v4
List pgsql-hackers
On Fri, Jan 18, 2013 at 11:33 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Andres Freund wrote:
>
>> [09] Adjust all *Satisfies routines to take a HeapTuple instead of a HeapTupleHeader
>>
>> For timetravel access to the catalog we need to be able to lookup (cmin,
>> cmax) pairs of catalog rows when were 'inside' that TX. This patch just
>> adapts the signature of the *Satisfies routines to expect a HeapTuple
>> instead of a HeapTupleHeader. The amount of changes for that is fairly
>> low as the HeapTupleSatisfiesVisibility macro already expected the
>> former.
>>
>> It also makes sure the HeapTuple fields are setup in the few places that
>> didn't already do so.
>
> I had a look at this part.  Running the regression tests unveiled a case
> where the tableOid wasn't being set (and thus caused an assertion to
> fail), so I added that.  I also noticed that the additions to
> pruneheap.c are sometimes filling a tuple before it's strictly
> necessary, leading to wasted work.  Moved those too.
>
> Looks good to me as attached.

I took a quick look at this and am just curious why we're adding the
requirement that t_tableOid has to be initialized?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: logical changeset generation v4
Next
From: Tom Lane
Date:
Subject: Re: proposal: fix corner use case of variadic fuctions usage