Gregory Stark <stark@enterprisedb.com> writes:
> Well it's never been a factor before so I'm not sure there is a
> policy. Is there now a policy that WAL files like database formats are
> as far as possible not going to be changed in minor versions?
> This means if there's a bug fix that affects WAL records the new point
> release will generally have to be patched to recognise the broken WAL
> records and process them correctly rather than simply generate
> corrected records. That could be quite a burden.
Let's see, so if we needed a bug fix that forced a tuple header layout
change or datatype representation change or page header change, your
position would be what exactly?
The project policy has always been that we don't change on-disk formats
in minor releases. I'm not entirely clear why you are so keen on
carving out an exception for WAL data.
While I can imagine bugs severe enough to make us violate that policy,
our track record of not having to is pretty good. And I don't see any
reason at all to suppose that such a bug would be more likely to affect
WAL (and only WAL) than any other part of our on-disk structures.
But having said all that, I'm not sure why we are arguing about it in
this context. There was an upthread mention that we ought to recommend
using identical executables on master and slave PITR systems, and I
think that's a pretty good recommendation in any case, because of the
variety of ways in which you could screw yourself through configuration
differences.
regards, tom lane