Re: logical changeset generation v4

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: logical changeset generation v4
Date: 2013-01-18 16:48:43
Message-ID: CA+TgmoZHs501D-p3gx-rZ56QvLqsJtVstp7d+VpAmMkr5HjS4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 18, 2013 at 11:33 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-18 16:55:16 Re: proposal: fix corner use case of variadic fuctions usage
Previous Message Alvaro Herrera 2013-01-18 16:45:21 Re: logical changeset generation v4