On 2013-12-03 15:40:44 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > I wondered about that myself. How would you suggest the format to look > > like? > > ISTM per tuple we'd need: > > > > * OffsetNumber off > > * uint16 infomask > > * TransactionId xmin > > * TransactionId xmax > > > > I don't see why we'd need infomask2, but so far being overly skimpy in > > that place hasn't shown itself to be the greatest idea?
> I don't see that we need the xmin; a simple bit flag indicating whether > the Xmin was frozen should be enough. Yea, that would work as well. > For xmax we need more detail, as you propose. In infomask, are you > proposing to store the complete infomask, or just the flags being > changed? Note we have a set of bits used in other wal records, > XLHL_XMAX_IS_MULTI and friends, which perhaps we can use here. Tentatively the complete one. I don't think we'd win enough by using compute_infobits/fix_infomask_from_infobits and we'd need to extend the bits stored in there unless we are willing to live with not transporting XMIN/XMAX_COMMITTED which doesn't seem like a good idea. Btw, why is it currently ok to modify the tuple in heap_freeze_tuple() without being in a critical section? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers