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
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...


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:

Reply via email to