Re: preserving forensic information when we freeze - Mailing list pgsql-hackers

From Robert Haas
Subject Re: preserving forensic information when we freeze
Date
Msg-id CA+Tgmob_D+0WNz-uFD8BQ7VRrn1mY0t8zy1t5ujq4wcBSHf6AQ@mail.gmail.com
Whole thread Raw
In response to Re: preserving forensic information when we freeze  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: preserving forensic information when we freeze
List pgsql-hackers
On Thu, Dec 19, 2013 at 9:19 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-12-19 07:40:40 -0500, Robert Haas wrote:
>> On Thu, Dec 19, 2013 at 5:44 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > On 2013-12-18 21:42:25 -0500, Robert Haas wrote:
>>
>> > I dislike transporting the
>> > infomask in the wal record and then changing it away from that again afterwards.
>>
>> I don't really see a problem with it.  Relying on the macros to tweak
>> the bits seems more future-proof than inventing some other way to do
>> it (that might even get copied into other parts of the code where it's
>> even less safe).
>
> Then there should be a macro to twiddle the infomask, without touching
> the tuple.

Sure, we can invent that.  I personally don't like it as well.

>>  I actually think transporting the infomask is kind
>> of a funky way to handle this in the first instance, but I don't think
>> it's this patch's job to kibitz that decision.
>
> It's not nice, I grant you that, but I don't see how to do it
> otherwise. We can't yet set the hint bits in
> heap_prepare_freeze_tuple(), as we're not in a critical section, and
> thus haven't replaced eventual multixacts by plain xids.
> Running it inside a critical section isn't really realistic, as we'd
> either have to iterate over the whole page, including memory
> allocations, inside one, or we'd have to WAL log each individual item.
>
> We could obviously encode all the infomask setting required in flags
> instructing heap_execute_freeze_tuple() to set them, but that seems more
> complex without accompanying benefit.

Abstraction is a benefit unto itself.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_rewarm status
Next
From: Tom Lane
Date:
Subject: Shouldn't IsBinaryCoercible accept targettype = ANYOID?