Re: 9.5 release notes

From: Andres Freund <andres(at)anarazel(dot)de>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: 9.5 release notes
Date: 2015-06-19 18:21:19
Message-ID: 20150619182119.GM29350@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2015-06-11 00:15:21 -0400, Bruce Momjian wrote:
> I have committed the first draft of the 9.5 release notes. You can view
> the output here:

So, I did a pass through master's state:

> <listitem>
> <para>
> Add <link linkend="BRIN">Block Range Indexes</> (<acronym>BRIN</>)
> (&Aacute;lvaro Herrera, Heikki Linnakangas, Emre Hasegeli)
> </para>
>
> <para>
> <acronym>BRIN</> indexes are very compact and store the min/max
> values for a range of heap blocks.
> </para>
> </listitem>

Maybe we should mention that they're cheap to maintain?

> <listitem>
> <para>
> Improve in-memory hash performance (Tomas Vondra, Robert Haas)
> </para>
> </listitem>

"hash performance" is pretty general, there's lot of places where we use
hashing that aren't affected.

> <listitem>
> <para>
> Improve concurrency of <link linkend="guc-shared-buffers">shared
> buffer</> replacement (Robert Haas, Amit Kapila)
> </para>
> </listitem>

I think in the end that patch was enhanced to a significant degree by
making it lockless in d72731a70450b. I think the three (?) involved
patches should just combined under one entry.

> <listitem>
> <para>
> Improve concurrent locking and buffer scan performance (Andres
> Freund, Kevin Grittner)
> </para>
> </listitem>

If this is ab5194e6f, I don't think it makes sense to mention "buffer
scan" - it's just any lwlock, and buffer locks aren't the primary
benefit (ProcArrayLock, buffer mapping lock probably are that). I also
don't think Kevin was involved?

I think ed127002d8 and 4b4b680c should be mentioned in this section as
well. 4b4b680c will considerably reduce the per backend memory usage for
servers with large shared buffers.

> <sect4>
> <title>Server Settings</title>
>
> <itemizedlist>
>
> <listitem>
> <para>
> Replace <varname>checkpoint_segments</> with <link
> linkend="guc-min-wal-size"><varname>min_wal_size</></> and
> <link linkend="guc-max-wal-size"><varname>max_wal_size</></>
> (Heikki Linnakangas)
> </para>
>
> <para>
> This allows the allocation of a large number of <acronym>WAL</>
> files without keeping them if they are not needed.
> </para>
> </listitem>

Hm. This affects performance significantly, should we also list it there?

> <listitem>
> <para>
> Add <acronym>GUC</> <link
> linkend="guc-wal-compression"><varname>wal_compression</></> to
> enable compression of full page images stored in <acronym>WAL</>
> (Rahila Syed, Michael Paquier)
> </para>
> </listitem>

Also rather performance relevant?

> <listitem>
> <para>
> Archive <acronym>WAL</> files with suffix <literal>.partial</>
> during standby promotion (Heikki Linnakangas)
> </para>
> </listitem>

This should be expanded, will mention to Heikki. Possibly also need to
be mentioned in the backward incompat section.

> <listitem>
> <para>
> Allow the <link linkend="pg-replication-origin-create">labeling</>
> of the origin of logical replication changes (Andres Freund)
> </para>
>
> <para>
> This helps with change tracking.
> </para>
> </listitem>

I think it should be 'origin and progress'. The explanation should
probably rather be 'This is helpful when implementing replication
solutions" or something like it.

> <listitem>
> <para>
> Allow control of table <acronym>WAL</> logging after table creation
> with <link linkend="SQL-ALTERTABLE"><command>ALTER TABLE .. SET
> LOGGED / UNLOGGED</></> (Fabr&iacute;zio de Royes Mello)
> </para>
> </listitem>

This sounds a bit confusing. Maybe "Allow to convert a WAL logged table
to an UNLOGGED one, and the other way round"?

> <sect4>
> <title>System Information Functions and Views</title>

I wonder if

> <listitem>
> <para>
> Report the backends holding replication slots in <link
> linkend="catalog-pg-replication-slots"><structname>pg_replication_slots</></>
> (Craig Ringer)
> </para>
>
> <para>
> The new output column is <structname>active_pid</>.
> </para>
> </listitem>

shouldn't be moved her?

> <listitem>
> <para>
> Allow <application>pg_dump</> to share a snapshot taken by another
> session using <option>--snapshot</> (Simon Riggs, Michael Paquier)
> </para>
>
> <para>
> The remote snapshot must have been exported by
> <function>pg_export_snapshot()</> or been defined when creating
> a logical replication slot.

'or exported by logical replication slot creation'?

> This can be used by parallel
> <application>pg_dump</> to use a consistent snapshot across
> <application>pg_dump</> processes.
> </para>

What do you mean by this comment? Parallel pg_dump internally does all
the snapshot stuff already, and it's independent of this option.

> <listitem>
> <para>
> Change <application>pg_ctl</> default shutdown mode from
> <literal>smart</> to <literal>fast</> (Bruce Momjian)
> </para>
> </listitem>

Wonder if this should be listed as an incompatibility. This does have
have impact on existing setups/scripts.

> <listitem>
> <para>
> Add basic atomics <acronym>API</> support (Andres Freund, Oskari
> Saarenmaa)
> </para>
> </listitem>

Out of fairness I think either Oskari shouldn't be listed, or Amit
should as well. Amit surely has spent more time on the patch than
Oskari.

> <listitem>
> <para>
> Add native compiler and memory barriers for <productname>Solaris
> Studio</> (Oskari Saarenmaa)
> </para>
>
> <para>
> IS THIS PART OF ATOMICS?
> </para>
> </listitem>

Not really, barriers are independent. But I guess we could just combine
it nonetheless.

> <sect3>
> <title>Additional Modules</title>
>
> <itemizedlist>
>
> <listitem>
> <para>
> Add <link linkend="app-pgrewind"><application>pg_rewind</></>,
> which allows re-synchronizing a master server after failback
> (Heikki Linnakangas)
> </para>
> </listitem>

Hm. pg_rewind isn't in contrib, so is this the right place for this?

I think 647248e3708, 4fe384bd85, 4f85fde8, 59f71a0d0 should also be
mentioned. They're amongst the most invasive changes in 9.5, and they do
have implications for developers and users.

f5ae3ba4/779fdcd should be listed as improving bitmap index scan
performance.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-06-19 18:26:56 Re: The real reason why TAP testing isn't ready for prime time
Previous Message Alvaro Herrera 2015-06-19 17:16:36 Re: The real reason why TAP testing isn't ready for prime time