On 24.04.2013 06:22, Bruce Momjian wrote:
On Tue, Apr 23, 2013 at 06:56:34PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Tue, Apr 23, 2013 at 05:04:15PM -0400, Bruce Momjian wrote:
Do we usually repeat the changes listed in the backwards
compatibility section later, in the "Changes" section? If not, then
instead of the first two items above, let's just have these in the
backwards-compatibility section:
We do not repeat the incompatibile items later in release notes. I have
added some of your text to one of the items, and added a mention that
tooling will need adjustment. Please check the post-commit version and
let me know about adjustments.
Let me clarify --- changes to our WAL binary format and source code
changes are not really incompatibilities from a user perspective as we
never promise to do our best to minimize such changes --- m eaning the
fact the WAL format changed is something that would be only in the
source code section and not in the "incompatibilities section" ---
incompatibilities are related to change in user experience or
documented-API changes.
These guidelines makes sense, except I think the change in naming
standard of xlog segments is important to document clearly because, even
if we have not promised compatibility, people could be relying on it in
scripts. I think it makes sense to waste a couple of lines documenting
this change, even if we expect the number of people to be bitten by it
to be very low.
Right. Kevin mentioned he had a script that knew about the numbering:
http://www.postgresql.org/message-id/4fd09b5e0200002500048...@gw.wicourts.gov.
Agreed. Here is the new text:
Store WAL in a continuous stream, rather than skipping the last
16MB segment every 4GB (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK
Previously, WAL files ending in FF were not used. If you have
WAL backup or restore scripts that took that skipping into account,
they need to be adjusted.
Looks good, thanks!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
