Re: 9.3 Beta1 status report

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.

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.

> Unrelated: I think this item
> Add configuration variable lock_timeout to limit lock wait duration
> (Zoltán Böszörményi)
> should go in the "locking" section. What's of interest here is the new
> feature to set maximum lock waits. The fact that this is done using a
> configuration variable is not that important.

Agreed. Moved. Thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +