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
