On 2013-12-01 15:54:41 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > Tom Lane <tgl@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
oflogging 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