On Thu, Dec 19, 2013 at 9:19 AM, Andres Freund <and...@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 <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers