On 2013-12-01 15:54:41 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > Tom Lane <t...@sss.pgh.pa.us> schrieb: > >> Uh ... what does the last have to do with it? Surely we don't run > >> VACUUM on replicas. Or are you talking about what might happen when > >> VACUUM is run on a former replica that's been promoted to master? > > > Unfortunately not. The problem is that xl_heap_freeze's redo function > > simply reexecutes heap-freeze-tuple() instead of logging much about each > > tuple... > > That was a pretty stupid choice ... we should think seriously about > changing that for 9.4. In general the application of a WAL record > needs to be 100% deterministic.
Completely agreed. I'm not really sure what led to that design choice except the desire to save a bit of WAL volume. It's a pretty old piece of code - a good while before I followed development in any form of detail. It's actually in the original commit (48188e1621bb6711e7d092bee48523b18cd80177) that introduced today's form of freezing. If it had been a more robust format all along, potential damage from the replication bug could have been fixed by a VACUUM FREEZE... 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
