From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 9.5 release notes |
Date: | 2015-06-11 15:11:48 |
Message-ID: | 20150611151148.GD19472@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 11, 2015 at 01:54:23PM +0900, Michael Paquier wrote:
> On Thu, Jun 11, 2015 at 1:15 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > I have committed the first draft of the 9.5 release notes. You can view
> > the output here:
> >
> > http://momjian.us/pgsql_docs/release-9-5.html
> >
> > and it will eventually appear here:
> >
> > http://www.postgresql.org/docs/devel/static/release.html
> >
> > I am ready to make suggested adjustments, though I am traveling for
> > conferences for the next ten days so there might a delay in my replies.
>
> Here are some review comments:
> + <para>
> + RETURN WHERE
> + </para>
> What is that?
It says the OID is returned, but where? I don't see it in psql.
> + <para>
> + WHAT IS A STATISTICS SNAPSHOT?
> + </para>
> + </listitem>
> It defines the last time when the global statistics file of pgstat has
> been written. Perhaps documentation should be made clearer.
Update with this text:
This represents the last time the snapshot files was written to
the file system.
> + <para>
> + The remote snapshot must have been exported by
> + <function>pg_export_snapshot()</> or been defined as a
> + logical replication slot. This can be used by parallel
> + <application>pg_dump</> to use a consistent snapshot across
> + <application>pg_dump</> processes.
> + </para>
> Perhaps "or been defined when creating a logical replication slot
> through a replication connection".
Sure, updated paragraph:
The remote snapshot must have been exported by
<function>pg_export_snapshot()</> or been defined when creating
a logical replication slot. This can be used by parallel
<application>pg_dump</> to use a consistent snapshot across
<application>pg_dump</> processes.
> + <listitem>
> + <para>
> + Simplify <acronym>WAL</> record format (Heikki Linnakangas)
> + </para>
> +
> + <para>
> + This allows external tools to more easily process <acronym>WAL</>
> + files.
> + </para>
> + </listitem>
> More precision could be brought here. What the new format allows is
> actually to track more easily what are the blocks modified for
> relations, something possible without having the knowledge of the
> record type directly.
OK, new text:
This allows external tools to more easily track what blocks
are modified.
> + <para>
> + This is particularly helpful for warm standbys.
> + </para>
> "for warm standbys to control the timing at which WAL segment files
> are retrieved from a WAL archive."
That feels redundant to the major description of the item.
> I think that the following items should be added as well:
> - Improvement of file version information for Windows builds (Noah
> Misch, Michael Paquier), commit ee9569e. The file version information
> was missing for a set of contrib modules as well as a handful of
> libraries and binaries (like conversion_procs, zic, pg_regress, etc.).
> This item should mention that all the binaries and libraries produced
> by a Windows build now contain file version information. This could be
> merged as well with this item as both are related:
> + <para>
> + Add icons to all <productname>MSVC</>-built binaries (Noah Misch)
> + </para>
OK, merged into the existing item:
Add icons to all <productname>MSVC</>-built binaries and version
information to all <systemitem class="osname">MS Windows</>
binaries (Noah Misch)
> - Move pg_lzcompress and pg_lzdecompress to libpqcommon, commit
> 40bede54. This was some legwork for wal_compression but external
> binary tools can take advantage of using it now more freely. Those
> APIs have been reworked as well to be more generic, somewhat similarly
> to the interface lz4 exposes to the user.
Uh, do we actually want to document that API for users? I didn't think so.
> - Addition of palloc_extended (8c8a886) to give module developers a
> fallback plan instead of OOM ERROR that palloc throws mandatorily.
> MemoryContextAllocExtended() can be used on another memory context
> than the current one similarly (bd4e2fd9). Feel free to discard this
> one if this is not appropriate in the release notes.
Same question. I am happy to mention it, but if we mention it, we are
encouraging people to use it.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2015-06-11 15:12:21 | Re: DBT-3 with SF=20 got failed |
Previous Message | Tom Lane | 2015-06-11 15:04:04 | Re: Entities created in one query not available in another in extended protocol |