>> 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.
> Agreed. It may suck, but it sucks less.
> How badly will it break if they do the upgrade in the wrong order though. > Will the slaves just stop (I assume this?) or is there a risk of a > wrong-order upgrade causing extra breakage?
I assume what would happen is the slave would PANIC upon seeing a WAL record code it didn't recognize. Installing the updated version should allow it to resume functioning. Would be good to test this, but if it doesn't work like that, that'd be another bug to fix IMO. We've always foreseen the possible need to do something like this, so it ought to work reasonably cleanly.
Yeah, as long as that's tested and actually works, that sounds like an acceptable thing to deal with.
> I assume we'd then get rid of the old record type completely in 9.4, right?
Yeah, we should be able to drop it in 9.4, since we'll surely have other WAL format changes anyway.
And even if not, there's no point in keeping it unless we actually support replication from 9.3 -> 9.4, I think, and I don't believe anybody has even considered working on that yet :)