Re: 9.3 Beta1 status report

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: 9.3 Beta1 status report
Date: 2013-04-23 21:04:15
Message-ID: 20130423210415.GC21856@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 23, 2013 at 02:25:08PM +0300, Heikki Linnakangas wrote:
> On 22.04.2013 23:06, Bruce Momjian wrote:
> >On Mon, Apr 22, 2013 at 10:11:48PM +0300, Heikki Linnakangas wrote:
> >>>E.1.3.2.1. Write-Ahead Log (WAL)
> >>>
> >>> Store WAL in a continuous stream, rather than skipping the last 16MB segment every 4GB (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK
> >>>
> >>> Restructure WAL files to better handle timeline changes during recovery (Heikki Linnakangas)
> >>>
> >>> Restructure WAL files to use a more compact storage format (Heikki Linnakangas)
> >>
> >>Can you clarify which commits these came from? The first one is
> >>clear (dfda6eba), and I think the 3rd covers commits 20ba5ca6 and
> >>061e7efb1. But what is that second entry?
> >
> >Frankly, I found the WAL and timeline commits all over the place and
> >could hardly make sense of it. I tried to collapse entries into
> >meaningful items, but I need help. Can you suggest changes?
>
> Ok:
>
> * Don't skip the last 16 MB WAL segment every 4GB, with filename
> ending in FF (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK

Uh, I am unclear why this is better than the original text. We don't
normally explain things like WAL file patterns in the release notes.
>
> * Change WAL record format, allowing the record header to be split
> across pages. The new format is slightly more compact. (Heikki
> Linnakangas)

Done.

> In "Source Code" section:
>
> * Use a 64-bit integer to represent WAL positions (XLogRecPtr),
> instead of two 32-bit integers. (Heikki Linnakangas)

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

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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-04-23 21:05:13 Re: 9.3 Beta1 status report
Previous Message Erikjan Rijkers 2013-04-23 21:00:31 Re: 9.3 Beta1 status report