On 2013-12-03 13:11:13 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > Any idea how to cheat our way out of that one given the current way > > heap_freeze_tuple() works (running on both primary and standby)? My only > > idea was to MultiXactIdWait() if !InRecovery but that's extremly grotty. > > We can't even realistically create a new multixact with fewer members > > with the current format of xl_heap_freeze. > > Maybe we should just bite the bullet and change the WAL format for > heap_freeze (inventing an all-new record type, not repurposing the old > one, and allowing WAL replay to continue to accept the old one). The > implication for users would be that they'd have to update slave servers > before the master when installing the update; which is unpleasant, but > better than living with a known data corruption case.
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? 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
