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

From Andres Freund
Subject Re: preserving forensic information when we freeze
Date
Msg-id 20131219141914.GA11483@alap2.anarazel.de
Whole thread Raw
In response to Re: preserving forensic information when we freeze  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: preserving forensic information when we freeze
List pgsql-hackers
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.

>  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.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_rewarm status
Next
From: Andres Freund
Date:
Subject: Re: pg_rewarm status