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.
That was my suggestion too (modulo, I admit, the bit about it being a new, separate record type.) -- Álvaro Herrera 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
