Thread: 9.3 Beta1 status report

I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2.  Those dates might change,
but that is the current plan.  I have completed a draft 9.3 release
notes, which you can view here:
http://momjian.us/pgsql_docs/release-9-3.html

I will be working on polishing them for the next ten days, so any
feedback, patches, or commits are welcome.  I still need to add lots of
SGML markup.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Sat, Apr 20, 2013 at 10:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
> I will be working on polishing them for the next ten days, so any
> feedback, patches, or commits are welcome.  I still need to add lots of
> SGML markup.

I've noticed a few things:

* Allow heap-only tuple updates on system tables (Andres Freund)

Didn't Andres just fix a bug wherein HOT updates usually wouldn't
occur on system tables following the commit of the foreign key locks
patch? While HOT's development occurred at a time before I followed
pgsql-hackers, I seem to recall someone telling me that Tom insisted
upon HOT working with system catalogs specifically because if it
wasn't good enough to work there, it wasn't good enough to work
anywhere, or something like that. I guess the source of the confusion
is specifically that at one point HOT really didn't work with system
catalogs. But, if I'm not mistaken, never in a released version.

* Improve grouping of sessions waiting for commit_delay (Peter Geoghegan)

I think this should be under "General Performance". It's definitely a
performance feature.

-- 
Peter Geoghegan

2013-04-21 07:02 keltezéssel, Bruce Momjian írta:
> I am not sure if Tom shared yet, but we are planning to package 9.3
> beta1 on April 29, with a release on May 2.  Those dates might change,
> but that is the current plan.  I have completed a draft 9.3 release
> notes, which you can view here:
>
>     http://momjian.us/pgsql_docs/release-9-3.html
>
> I will be working on polishing them for the next ten days, so any
> feedback, patches, or commits are welcome.  I still need to add lots of
> SGML markup.

How comes Álvaro's name comes out right in your page but not at
http://www.postgresql.org/docs/devel/static/release-9-3.html ?

Anyway, I attached a patch to fix my name in your page using markups.

Thanks,
Zoltán Böszörményi


--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
      http://www.postgresql.at/

On 2013-04-20 22:36:32 -0700, Peter Geoghegan wrote:
> On Sat, Apr 20, 2013 at 10:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > I will be working on polishing them for the next ten days, so any
> > feedback, patches, or commits are welcome.  I still need to add lots of
> > SGML markup.
> 
> I've noticed a few things:
> 
> * Allow heap-only tuple updates on system tables (Andres Freund)
> 
> Didn't Andres just fix a bug wherein HOT updates usually wouldn't
> occur on system tables following the commit of the foreign key locks
> patch?

Yes, that definitely was a bugfix for a HEAD only feature.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

On Sat, Apr 20, 2013 at 10:36:32PM -0700, Peter Geoghegan wrote:
> * Improve grouping of sessions waiting for commit_delay (Peter Geoghegan)
> 
> I think this should be under "General Performance". It's definitely a
> performance feature.

OK, moved.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Sun, Apr 21, 2013 at 09:34:10AM +0200, Boszormenyi Zoltan wrote:
> 2013-04-21 07:02 keltezéssel, Bruce Momjian írta:
> >I am not sure if Tom shared yet, but we are planning to package 9.3
> >beta1 on April 29, with a release on May 2.  Those dates might change,
> >but that is the current plan.  I have completed a draft 9.3 release
> >notes, which you can view here:
> >
> >    http://momjian.us/pgsql_docs/release-9-3.html
> >
> >I will be working on polishing them for the next ten days, so any
> >feedback, patches, or commits are welcome.  I still need to add lots of
> >SGML markup.
> 
> How comes Álvaro's name comes out right in your page but not at
> http://www.postgresql.org/docs/devel/static/release-9-3.html ?
> 
> Anyway, I attached a patch to fix my name in your page using markups.

Thanks, applied.  I had not yet gotten to doing the SGML markup for
non-ASCII characters.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Sun, Apr 21, 2013 at 02:45:42PM +0400, Alexander Korotkov wrote:
> On Sun, Apr 21, 2013 at 9:02 AM, Bruce Momjian <bruce@momjian.us> wrote:
> 
>     I am not sure if Tom shared yet, but we are planning to package 9.3
>     beta1 on April 29, with a release on May 2.  Those dates might change,
>     but that is the current plan.  I have completed a draft 9.3 release
>     notes, which you can view here:
> 
>             http://momjian.us/pgsql_docs/release-9-3.html
> 
>     I will be working on polishing them for the next ten days, so any
>     feedback, patches, or commits are welcome.  I still need to add lots of
>     SGML markup
> 
> 
> * Collect and use histograms of lower and upper bounds for range types
> (Alexander Korotkov)
> 
> Actually, we also collect histogram of range lengths. Probably, we can rephrase
> it more generally, like "Collect and use special statistics for range types".

Done, thanks.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

Bruce,

I don't see parallel pg_dump in the release notes.  I thought that got
committed?

Anyway, see the pgsql-advocacy list for a longish discussion about what
we should consider the "major" fetures for 9.3.


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On 2013-04-21 14:50:07 -0700, Josh Berkus wrote:
> Bruce,
> 
> I don't see parallel pg_dump in the release notes.  I thought that got
> committed?


E.1.3.8.2. pg_dump:   Add pg_dump --jobs to dump in parallel when using directory output   format (Joachim Wieland)

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

2013-04-21 15:10 keltezéssel, Bruce Momjian írta:
> On Sun, Apr 21, 2013 at 09:34:10AM +0200, Boszormenyi Zoltan wrote:
>> 2013-04-21 07:02 keltezéssel, Bruce Momjian írta:
>>> I am not sure if Tom shared yet, but we are planning to package 9.3
>>> beta1 on April 29, with a release on May 2.  Those dates might change,
>>> but that is the current plan.  I have completed a draft 9.3 release
>>> notes, which you can view here:
>>>
>>>     http://momjian.us/pgsql_docs/release-9-3.html
>>>
>>> I will be working on polishing them for the next ten days, so any
>>> feedback, patches, or commits are welcome.  I still need to add lots of
>>> SGML markup.
>> How comes Álvaro's name comes out right in your page but not at
>> http://www.postgresql.org/docs/devel/static/release-9-3.html ?
>>
>> Anyway, I attached a patch to fix my name in your page using markups.
> Thanks, applied.

Thank you.

>    I had not yet gotten to doing the SGML markup for
> non-ASCII characters.
>


--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de     http://www.postgresql.at/

Bruce Momjian wrote:
> I am not sure if Tom shared yet, but we are planning to package 9.3
> beta1 on April 29, with a release on May 2.  Those dates might change,
> but that is the current plan.  I have completed a draft 9.3 release
> notes, which you can view here:
>
>     http://momjian.us/pgsql_docs/release-9-3.html
>
> I will be working on polishing them for the next ten days, so any
> feedback, patches, or commits are welcome.  I still need to add lots of
> SGML markup.

Can you please clarify the policy on attaching people's names to items?

This item Have DROP OWNED only remove user-matching GRANTs on shared objects, e.g. databases, tablespaces (Álvaro
Herrera)
was a backpatched bugfix; I don't think it should be listed.


This item Throw an error if expiring tuple is again updated or deleted (Kevin Grittner) KEEP?

not only needs to be kept, but is also a backward-incompatible change,
so I think it warrants a more verbose explanation.


This item Improve the ability to detect indexable prefixes in regular expressions (Tom Lane)
I'm not really sure about it.  Isn't it about the new pg_trgm code to
support regex indexes?  I think they either belong together, or perhaps
the one in "optimizer" shouldn't be listed.

This item Implement a generic binary heap and use it for Merge-Append operations (Abhijit Menon-Sen)

A generic binary heap was implemented; but merge-append was already
using their own binary heap.  So this is not a performance optimization.
I think the item should be moved down to the "source code" section.

There's an extra double quote here: "Allow in-memory sorts to use their full memory allocation (Jeff Janes)


This item: Allow heap-only tuple updates on system tables (Andres Freund)
was a bug fix; item should be removed.


Shouldn't this one Add function to report the size of the GIN pending index insertion list (Fujii Masao)
be in the "additional modules" section?


In this item Add support to event triggers (Dimitri Fontaine, Tom Lane)
I am not sure why you list Tom.  I think Robert should be listed
instead.


In this this Internally store default foreign key matches (non-FULL, non-PARTIAL) as "simple" (Tom Lane)
there is something funny going on with & chars around unspecified.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Apr 22, 2013 at 01:54:03PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I am not sure if Tom shared yet, but we are planning to package 9.3
> > beta1 on April 29, with a release on May 2.  Those dates might change,
> > but that is the current plan.  I have completed a draft 9.3 release
> > notes, which you can view here:
> > 
> >     http://momjian.us/pgsql_docs/release-9-3.html
> > 
> > I will be working on polishing them for the next ten days, so any
> > feedback, patches, or commits are welcome.  I still need to add lots of
> > SGML markup.
> 
> Can you please clarify the policy on attaching people's names to items?

Well, I just pull them from the commit message, of it no one is
mentioned in the commit message, I use the committer's name.

> This item
>   Have DROP OWNED only remove user-matching GRANTs on shared objects, e.g.
>   databases, tablespaces (Álvaro Herrera)
> was a backpatched bugfix; I don't think it should be listed.

OK, removed.  I now see there was a backpatch mention in the commit
messsage.

> This item
>   Throw an error if expiring tuple is again updated or deleted (Kevin
>   Grittner) KEEP?
> 
> not only needs to be kept, but is also a backward-incompatible change,
> so I think it warrants a more verbose explanation.

OK, I don't understand myself, so I will need details.  I marked it as
backward-incompatible.

> This item
>   Improve the ability to detect indexable prefixes in regular
>   expressions (Tom Lane)
> I'm not really sure about it.  Isn't it about the new pg_trgm code to
> support regex indexes?  I think they either belong together, or perhaps
> the one in "optimizer" shouldn't be listed.

I have no idea.  I certainly see it affecting more than pg_trgm;  I see
backend regression test additions with the patch, 
628cbb50ba80c83917b07a7609ddec12cda172d0.

> This item
>   Implement a generic binary heap and use it for Merge-Append operations
>   (Abhijit Menon-Sen)
> 
> A generic binary heap was implemented; but merge-append was already
> using their own binary heap.  So this is not a performance optimization.
> I think the item should be moved down to the "source code" section.

OK.


> There's an extra double quote here:
>   "Allow in-memory sorts to use their full memory allocation (Jeff Janes)

Fixed.
> 
> This item:
>   Allow heap-only tuple updates on system tables (Andres Freund)
> was a bug fix; item should be removed.

OK.

> Shouldn't this one
>   Add function to report the size of the GIN pending index insertion
>   list (Fujii Masao)
> be in the "additional modules" section?

Yes, moved.

> In this item
>   Add support to event triggers (Dimitri Fontaine, Tom Lane)
> I am not sure why you list Tom.  I think Robert should be listed
> instead.

Tom did a massive fix/cleanup of that code.  I have added Robert.

> In this this
>   Internally store default foreign key matches (non-FULL, non-PARTIAL) as
>   "simple" (Tom Lane)
> there is something funny going on with & chars around unspecified.

Fixed, and applied.

Thanks!

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

> Allow tooling like pg_receivexlog to run on computers with different architectures (Heikki Linnakangas)

This probably should be mentioned in the backwards-compatibility 
section. Any 3rd party tools that speak the streaming replication 
protocol are affected.

> 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)
BACKWARDCOMPATIBLE 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?

- Heikki

On Mon, Apr 22, 2013 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> In this item
>>   Add support to event triggers (Dimitri Fontaine, Tom Lane)
>> I am not sure why you list Tom.  I think Robert should be listed
>> instead.
>
> Tom did a massive fix/cleanup of that code.  I have added Robert.

I do not think that is true.  To what commit IDs are you referring?  I
think this item should credit Dimitri, myself, and Alvaro, probably in
that order.  The only commit by Tom to event_triggers.c is
cd3413ec3683918c9cb9cfb39ae5b2c32f231e8b, which is hardly a "massive
fix/cleanup".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Bruce Momjian wrote:
> On Mon, Apr 22, 2013 at 01:54:03PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > I am not sure if Tom shared yet, but we are planning to package 9.3
> > > beta1 on April 29, with a release on May 2.  Those dates might change,
> > > but that is the current plan.  I have completed a draft 9.3 release
> > > notes, which you can view here:
> > >
> > >     http://momjian.us/pgsql_docs/release-9-3.html
> > >
> > > I will be working on polishing them for the next ten days, so any
> > > feedback, patches, or commits are welcome.  I still need to add lots of
> > > SGML markup.
> >
> > Can you please clarify the policy on attaching people's names to items?
>
> Well, I just pull them from the commit message, of it no one is
> mentioned in the commit message, I use the committer's name.

Hm, I listed code authors in roughly chronological order in 0ac5ad51
(fklocks).  I think that patch should list me, Noah, Andres, Alex,
Marti.

> > This item
> >   Improve the ability to detect indexable prefixes in regular
> >   expressions (Tom Lane)
> > I'm not really sure about it.  Isn't it about the new pg_trgm code to
> > support regex indexes?  I think they either belong together, or perhaps
> > the one in "optimizer" shouldn't be listed.
>
> I have no idea.  I certainly see it affecting more than pg_trgm;  I see
> backend regression test additions with the patch,
> 628cbb50ba80c83917b07a7609ddec12cda172d0.

Ah, yeah, it's unrelated to pg_trgm indexing.  It's a (backpatched) bug
fix, though.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Apr 22, 2013 at 03:19:36PM -0400, Robert Haas wrote:
> On Mon, Apr 22, 2013 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> In this item
> >>   Add support to event triggers (Dimitri Fontaine, Tom Lane)
> >> I am not sure why you list Tom.  I think Robert should be listed
> >> instead.
> >
> > Tom did a massive fix/cleanup of that code.  I have added Robert.
> 
> I do not think that is true.  To what commit IDs are you referring?  I
> think this item should credit Dimitri, myself, and Alvaro, probably in
> that order.  The only commit by Tom to event_triggers.c is
> cd3413ec3683918c9cb9cfb39ae5b2c32f231e8b, which is hardly a "massive
> fix/cleanup".

OK, changed.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Mon, Apr 22, 2013 at 04:48:58PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, Apr 22, 2013 at 01:54:03PM -0300, Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > I am not sure if Tom shared yet, but we are planning to package 9.3
> > > > beta1 on April 29, with a release on May 2.  Those dates might change,
> > > > but that is the current plan.  I have completed a draft 9.3 release
> > > > notes, which you can view here:
> > > > 
> > > >     http://momjian.us/pgsql_docs/release-9-3.html
> > > > 
> > > > I will be working on polishing them for the next ten days, so any
> > > > feedback, patches, or commits are welcome.  I still need to add lots of
> > > > SGML markup.
> > > 
> > > Can you please clarify the policy on attaching people's names to items?
> > 
> > Well, I just pull them from the commit message, of it no one is
> > mentioned in the commit message, I use the committer's name.
> 
> Hm, I listed code authors in roughly chronological order in 0ac5ad51
> (fklocks).  I think that patch should list me, Noah, Andres, Alex,
> Marti.

OK, I have now listed them in the order you specified.

> > > This item
> > >   Improve the ability to detect indexable prefixes in regular
> > >   expressions (Tom Lane)
> > > I'm not really sure about it.  Isn't it about the new pg_trgm code to
> > > support regex indexes?  I think they either belong together, or perhaps
> > > the one in "optimizer" shouldn't be listed.
> > 
> > I have no idea.  I certainly see it affecting more than pg_trgm;  I see
> > backend regression test additions with the patch, 
> > 628cbb50ba80c83917b07a7609ddec12cda172d0.
> 
> Ah, yeah, it's unrelated to pg_trgm indexing.  It's a (backpatched) bug
> fix, though.

OK, removed.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Mon, Apr 22, 2013 at 10:11:48PM +0300, Heikki Linnakangas wrote:
> >Allow tooling like pg_receivexlog to run on computers with different architectures (Heikki Linnakangas)
> 
> This probably should be mentioned in the backwards-compatibility
> section. Any 3rd party tools that speak the streaming replication
> protocol are affected.
> 
> >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)
BACKWARDCOMPATIBLE 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?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

Some more diacritics ..

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Apr 22, 2013 at 05:53:43PM -0300, Alvaro Herrera wrote:
> 
> Some more diacritics ..

Thanks, applied.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On 21 April 2013 06:02, Bruce Momjian <bruce@momjian.us> wrote:
> I am not sure if Tom shared yet, but we are planning to package 9.3
> beta1 on April 29, with a release on May 2.  Those dates might change,
> but that is the current plan.  I have completed a draft 9.3 release
> notes, which you can view here:
>
>         http://momjian.us/pgsql_docs/release-9-3.html
>
> I will be working on polishing them for the next ten days, so any
> feedback, patches, or commits are welcome.  I still need to add lots of
> SGML markup.
>

E.1.3.4.4. VIEWs:

* Make simple views auto-updatable (Dean Rasheed)
 INSTEAD rules are still available for complex views.


I think this should refer to INSTEAD OF triggers for complex views,
since that is now the recommended way to implement updatable views.

I think it should also expand a little on what "simple" means in this
context, without going into all the gory details, and mention that
there is a behaviour change. So perhaps something like this for the
second paragraph:
       Simple views that select some or all columns from a single base table       are now updatable by default. More
complexviews can be made updatable       using INSTEAD OF triggers or INSTEAD rules.
 

Regards,
Dean

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)
BACKWARDCOMPATIBLE 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

* Change WAL record format, allowing the record header to be split 
across pages. The new format is slightly more compact. (Heikki Linnakangas)

In "Source Code" section:

* Use a 64-bit integer to represent WAL positions (XLogRecPtr), instead 
of two 32-bit integers. (Heikki Linnakangas)


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:

* The WAL file numbering has changed to not skip WAL files ending with FF.
  If you have e.g backup / restore scripts that took the skipping into  account, they need to be adjusted.

* The WAL format has changed.
  Any external tools that read the WAL files need to be adjusted to  understand the new format. The new xlogreader
facilityhelps  writing such tools.
 

- Heikki

On Tue, Apr 23, 2013 at 10:12:58AM +0100, Dean Rasheed wrote:
> On 21 April 2013 06:02, Bruce Momjian <bruce@momjian.us> wrote:
> > I am not sure if Tom shared yet, but we are planning to package 9.3
> > beta1 on April 29, with a release on May 2.  Those dates might change,
> > but that is the current plan.  I have completed a draft 9.3 release
> > notes, which you can view here:
> >
> >         http://momjian.us/pgsql_docs/release-9-3.html
> >
> > I will be working on polishing them for the next ten days, so any
> > feedback, patches, or commits are welcome.  I still need to add lots of
> > SGML markup.
> >
> 
> E.1.3.4.4. VIEWs:
> 
> * Make simple views auto-updatable (Dean Rasheed)
> 
>   INSTEAD rules are still available for complex views.
> 
> 
> I think this should refer to INSTEAD OF triggers for complex views,
> since that is now the recommended way to implement updatable views.
> 
> I think it should also expand a little on what "simple" means in this
> context, without going into all the gory details, and mention that
> there is a behaviour change. So perhaps something like this for the
> second paragraph:
> 
>         Simple views that select some or all columns from a single base table
>         are now updatable by default. More complex views can be made updatable
>         using INSTEAD OF triggers or INSTEAD rules.

I like it!   Done.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Tue, Apr 23, 2013 at 05:36:03PM +0800, Jov wrote:
> E.1.3.1.4：
> 
> Improve performance of the CREATE TABLE ... ON COMMIT DELETE ROWS clause by
> only issuing delete if the temporary table was accessed (Heikki Linnakangas)
> 
> should be:
>              CREATE TEMP TABLE ... ON COMMIT DELETE ROWS
> or
>            CREATE { TEMPORARY | TEMP } TABLE ... ON COMMIT DELETE ROWS
> 
> because there is no syntax for CREATE TABLE ... ON COMMIT DELETE ROWS

Oh, good point.  Fixed.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

I just spotted some more small stuff:

s/IF NOT EXIST /IF NOT EXISTS /g   # 2 x


It actually had me doubting, but yes that -S should be there...


Thanks,

Erik Rijkers

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)
BACKWARDCOMPATIBLE 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Tue, Apr 23, 2013 at 11:00:31PM +0200, Erikjan Rijkers wrote:
> I just spotted some more small stuff:
> 
> s/IF NOT EXIST /IF NOT EXISTS /g   # 2 x
> 
> 
> It actually had me doubting, but yes that -S should be there...

Fixed, thanks.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

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.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

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.

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.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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
thatskipping 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

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/4FD09B5E020000250004818B@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

On 04/24/2013 06:34 PM, Heikki Linnakangas wrote:
>>>> 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/4FD09B5E020000250004818B@gw.wicourts.gov.
>

We also have scripts that know about the missing FF.  How slim are the
chances of having pg_xlogdump output the version of the wal file for
9.3?  I know we're right on top of the deadline, but that tool and this
change are both new to 9.3. That way our scripts could know if a file is
missing or not.

I talked about this briefly with Andres on IRC and he says a patch to do
this would be trivial.

Thoughts?

On 25.04.2013 12:43, Vik Fearing wrote:
> On 04/24/2013 06:34 PM, Heikki Linnakangas wrote:
>>>>> 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/4FD09B5E020000250004818B@gw.wicourts.gov.
>
> We also have scripts that know about the missing FF.  How slim are the
> chances of having pg_xlogdump output the version of the wal file for
> 9.3?  I know we're right on top of the deadline, but that tool and this
> change are both new to 9.3. That way our scripts could know if a file is
> missing or not.
>
> I talked about this briefly with Andres on IRC and he says a patch to do
> this would be trivial.

Seems reasonable. Patches are welcome :-). We're not going to guarantee 
that pg_xlogdump works across versions, but printing out the version 
that generated the file seems easy enough. If your script has access to 
the data directory, you could also easily check PG_VERSION.

- Heikki

Bruce,

So here's my draft list of "Major Enhancements" for the relase notes:

* Writeable Foreign Tables
* pgsql_fdw driver for federation of PostgreSQL databases
* Automatically updatable VIEWs
* MATERIALIZED VIEW declaration
* LATERAL JOINs
* Additional JSON constructor and extractor functions
* Indexed regular expression search
* Disk page checksums to detect filesystem failures
* Streaming-only remastering of replicas
* Performance and locking improvements for Foreign Key locks
* Parallel pg_dump for faster backups
* Directories for configuration files
* pg_isready database connection checker
* COPY FREEZE for reduced IO bulk loading
* User-defined background workers for automating database tasks
* Recursive view declaration

I note that the first one I'm leading off with actually isn't included
in your release notes.  So please add it:

Allow foreign data wrappers to accept writesForeign data sources can now be written to,as well as read, provided that
theFDW driversupports it.
 

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Sat, Apr 27, 2013 at 05:29:51PM -0700, Josh Berkus wrote:
> Bruce,
> 
> So here's my draft list of "Major Enhancements" for the relase notes:
> 
> * Writeable Foreign Tables
> * pgsql_fdw driver for federation of PostgreSQL databases
> * Automatically updatable VIEWs
> * MATERIALIZED VIEW declaration
> * LATERAL JOINs
> * Additional JSON constructor and extractor functions
> * Indexed regular expression search
> * Disk page checksums to detect filesystem failures
> * Streaming-only remastering of replicas
> * Performance and locking improvements for Foreign Key locks
> * Parallel pg_dump for faster backups
> * Directories for configuration files
> * pg_isready database connection checker
> * COPY FREEZE for reduced IO bulk loading
> * User-defined background workers for automating database tasks
> * Recursive view declaration
> 
> I note that the first one I'm leading off with actually isn't included
> in your release notes.  So please add it:
> 
> Allow foreign data wrappers to accept writes
>     Foreign data sources can now be written to,
>     as well as read, provided that the FDW driver
>     supports it.

Well, this is the text I have now, which was suggested to me:
     <listitem>      <para>       Add a Postgres foreign data wrapper contrib module (Shigeru       Hanada, KaiGai
Kohei)     </para>
 
      <para>       This foreign data wrapper allows writes;  potentially other       foreign data wrappers can now
supportwrites.      </para>     </listitem>
 

Are you saying split up this into two items?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

>       <listitem>
>        <para>
>         Add a Postgres foreign data wrapper contrib module (Shigeru
>         Hanada, KaiGai Kohei)
>        </para>
> 
>        <para>
>         This foreign data wrapper allows writes;  potentially other
>         foreign data wrappers can now support writes.
>        </para>
>       </listitem>
> 
> Are you saying split up this into two items?

Yes, because it's two separate features.

I know Andrew plans to have a writeable Redis FDW before 9.3 is
released, for one.


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Thu, May  2, 2013 at 02:09:21PM -0700, Josh Berkus wrote:
> 
> >       <listitem>
> >        <para>
> >         Add a Postgres foreign data wrapper contrib module (Shigeru
> >         Hanada, KaiGai Kohei)
> >        </para>
> > 
> >        <para>
> >         This foreign data wrapper allows writes;  potentially other
> >         foreign data wrappers can now support writes.
> >        </para>
> >       </listitem>
> > 
> > Are you saying split up this into two items?
> 
> Yes, because it's two separate features.
> 
> I know Andrew plans to have a writeable Redis FDW before 9.3 is
> released, for one.

OK, I have split them apart:
     <listitem>      <para>       Allow write-enabled foreign data wrappers to support writes       (KaiGai Kohei)
</para>    </listitem>
 
     <listitem>      <para>       Add a Postgres foreign data wrapper contrib module (Shigeru       Hanada)
</para>
      <para>       This foreign data wrapper allows writes.      </para>     </listitem>

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Thu, May  2, 2013 at 03:03:58PM -0700, Jeff Janes wrote:
> Some suggestions, perhaps just based on my preference for verbosity:
> 
> 
>        <para>
>         Add cache of local locks (Jeff Janes)
>        </para>
> 
>        <para>
>         This speeds lock release at statement completion in transactions
>         that hold many locks; it is particularly useful for pg_dump.
>        </para>
> 
> 
> I think this is equally important for restoration of dumps, if the restoration
> is run all in one transaction.  (Making the dump and restoring it have similar
> locking and unlocking patterns)

Do you have proposed wording?  I can't say just dump/restore as it only
helps with _logical_ dump and _logical_ restore, and we don't have a
clear word for logical restore, as it could be pg_restore or piped into
psql.  We could do:
       that hold many locks; it is particularly useful for pg_dump and restore.

but "restore" seems very vague.

>        <para>
>         Split pgstat file in per-database and global files (Tomas Vondra)
>        </para>
> 
>        <para>
>         This reduces the statistics management read and write overhead.
>        </para>
> 
> 
> Should be "split pgstat file into", not "split pgstat file in"

That one was easy, fixed.

> Also, should it mention that the overhead reduction is particular to when a
> cluster has a large number of databases? 

Well, if you have just two databases with many tables, it still helps.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On 05/05/2013 05:16 PM, Jeff Janes wrote:
> On Thu, May 2, 2013 at 4:13 PM, Bruce Momjian <bruce@momjian.us 
> <mailto:bruce@momjian.us>> wrote:
>
>     On Thu, May  2, 2013 at 03:03:58PM -0700, Jeff Janes wrote:
>     > Some suggestions, perhaps just based on my preference for verbosity:
>     >
>     >
>     >        <para>
>     >         Add cache of local locks (Jeff Janes)
>     >        </para>
>     >
>     >        <para>
>     >         This speeds lock release at statement completion in
>     transactions
>     >         that hold many locks; it is particularly useful for pg_dump.
>     >        </para>
>     >
>     >
>     > I think this is equally important for restoration of dumps, if
>     the restoration
>     > is run all in one transaction.  (Making the dump and restoring
>     it have similar
>     > locking and unlocking patterns)
>
>     Do you have proposed wording?  I can't say just dump/restore as it
>     only
>     helps with _logical_ dump and _logical_ restore, and we don't have a
>     clear word for logical restore, as it could be pg_restore or piped
>     into
>     psql.  We could do:
>
>             that hold many locks; it is particularly useful for
>     pg_dump and restore.
>
>     but "restore" seems very vague.
>
>
>
> Yeah, I wasn't sure about how to work that either.
>
> "...and the restore of such dumps."?
>

s/restore/restoration/

cheers

andrew

On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
> I am not sure if Tom shared yet, but we are planning to package 9.3
> beta1 on April 29, with a release on May 2.  Those dates might change,
> but that is the current plan.  I have completed a draft 9.3 release
> notes, which you can view here:
> 
>     http://momjian.us/pgsql_docs/release-9-3.html
> 
> I will be working on polishing them for the next ten days, so any
> feedback, patches, or commits are welcome.  I still need to add lots of
> SGML markup.

1. 
.Add wal_receiver_timeout parameter to control the WAL receiver timeout
(Amit Kapila) 
This allows more rapid detection of connection failure. No longer set
wal_receiver_status_interval? 

I don't think we need to mention anything about
wal_receiver_status_interval.

2. I am not able to figure out which item of release notes cover the below
feature commit
Avoid inserting Result nodes that only compute identity projections.
http://www.postgresql.org/message-id/E1UGCBh-0006P3-A0@gemulon.postgresql.or
g

With Regards,
Amit Kapila.

On Mon, May  6, 2013 at 12:43:55PM +0530, Amit Kapila wrote:
> On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
> > I am not sure if Tom shared yet, but we are planning to package 9.3
> > beta1 on April 29, with a release on May 2.  Those dates might change,
> > but that is the current plan.  I have completed a draft 9.3 release
> > notes, which you can view here:
> > 
> >     http://momjian.us/pgsql_docs/release-9-3.html
> > 
> > I will be working on polishing them for the next ten days, so any
> > feedback, patches, or commits are welcome.  I still need to add lots of
> > SGML markup.
> 
> 1. 
> .Add wal_receiver_timeout parameter to control the WAL receiver timeout
> (Amit Kapila) 
> This allows more rapid detection of connection failure. No longer set
> wal_receiver_status_interval? 
> 
> I don't think we need to mention anything about
> wal_receiver_status_interval.

OK, removed.

> 2. I am not able to figure out which item of release notes cover the below
> feature commit
> Avoid inserting Result nodes that only compute identity projections.
> http://www.postgresql.org/message-id/E1UGCBh-0006P3-A0@gemulon.postgresql.org

I did not think that warranted a mention in the release notes.  Was I
wrong?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Sun, May  5, 2013 at 02:16:59PM -0700, Jeff Janes wrote:
> On Thu, May 2, 2013 at 4:13 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 
>     On Thu, May  2, 2013 at 03:03:58PM -0700, Jeff Janes wrote:
>     > Some suggestions, perhaps just based on my preference for verbosity:
>     >
>     >
>     >        <para>
>     >         Add cache of local locks (Jeff Janes)
>     >        </para>
>     >
>     >        <para>
>     >         This speeds lock release at statement completion in transactions
>     >         that hold many locks; it is particularly useful for pg_dump.
>     >        </para>
>     >
>     >
>     > I think this is equally important for restoration of dumps, if the
>     restoration
>     > is run all in one transaction.  (Making the dump and restoring it have
>     similar
>     > locking and unlocking patterns)
> 
>     Do you have proposed wording?  I can't say just dump/restore as it only
>     helps with _logical_ dump and _logical_ restore, and we don't have a
>     clear word for logical restore, as it could be pg_restore or piped into
>     psql.  We could do:
> 
>             that hold many locks; it is particularly useful for pg_dump and
>     restore.
> 
>     but "restore" seems very vague.
> 
> 
> 
> Yeah, I wasn't sure about how to work that either.
> 
> "...and the restore of such dumps."?

s/restore/restoring/

I like it.  Done.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Sun, May  5, 2013 at 06:59:28PM -0400, Andrew Dunstan wrote:
> >    > I think this is equally important for restoration of dumps, if
> >    the restoration
> >    > is run all in one transaction.  (Making the dump and restoring
> >    it have similar
> >    > locking and unlocking patterns)
> >
> >    Do you have proposed wording?  I can't say just dump/restore as it
> >    only
> >    helps with _logical_ dump and _logical_ restore, and we don't have a
> >    clear word for logical restore, as it could be pg_restore or piped
> >    into
> >    psql.  We could do:
> >
> >            that hold many locks; it is particularly useful for
> >    pg_dump and restore.
> >
> >    but "restore" seems very vague.
> >
> >
> >
> >Yeah, I wasn't sure about how to work that either.
> >
> >"...and the restore of such dumps."?
> >
> 
> s/restore/restoration/

I like that even better!  Done.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Monday, May 06, 2013 8:17 PM Bruce Momjian wrote:
> On Mon, May  6, 2013 at 12:43:55PM +0530, Amit Kapila wrote:
> > On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
> > > I am not sure if Tom shared yet, but we are planning to package 9.3
> > > beta1 on April 29, with a release on May 2.  Those dates might
> change,
> > > but that is the current plan.  I have completed a draft 9.3 release
> > > notes, which you can view here:
> > >
> > >     http://momjian.us/pgsql_docs/release-9-3.html
> > >
> > > I will be working on polishing them for the next ten days, so any
> > > feedback, patches, or commits are welcome.  I still need to add
> lots of
> > > SGML markup.
> >
> > 1.
> > .Add wal_receiver_timeout parameter to control the WAL receiver
> timeout
> > (Amit Kapila)
> > This allows more rapid detection of connection failure. No longer set
> > wal_receiver_status_interval?
> >
> > I don't think we need to mention anything about
> > wal_receiver_status_interval.
> 
> OK, removed.

Thanks.

> > 2. I am not able to figure out which item of release notes cover the
> below
> > feature commit
> > Avoid inserting Result nodes that only compute identity projections.
> > http://www.postgresql.org/message-id/E1UGCBh-0006P3-
> A0@gemulon.postgresql.org
> 
> I did not think that warranted a mention in the release notes.  Was I
> wrong?

This was a performance improvement for a quite usable scenario, so I thought
it would be useful for users to know about it.
Performance data for simple cases I have posted:
http://www.postgresql.org/message-id/007e01ce08ff$dc0a2c60$941e8520$@kapila@
huawei.com


With Regards,
Amit Kapila.

On Tue, May  7, 2013 at 10:23:48AM +0530, Amit Kapila wrote:
> > > 2. I am not able to figure out which item of release notes cover the
> > below
> > > feature commit
> > > Avoid inserting Result nodes that only compute identity projections.
> > > http://www.postgresql.org/message-id/E1UGCBh-0006P3-
> > A0@gemulon.postgresql.org
> > 
> > I did not think that warranted a mention in the release notes.  Was I
> > wrong?
> 
> This was a performance improvement for a quite usable scenario, so I thought
> it would be useful for users to know about it.
> Performance data for simple cases I have posted:
> http://www.postgresql.org/message-id/007e01ce08ff$dc0a2c60$941e8520$@kapila@
> huawei.com

I usually mention items that have a user-visible change, or are easy to
explain, or apply to most queries.  I am not sure this falls into any of
those categories.

Can you suggest some release note text for this item?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Thursday, May 16, 2013 7:17 PM Bruce Momjian wrote:
> On Tue, May  7, 2013 at 10:23:48AM +0530, Amit Kapila wrote:
> > > > 2. I am not able to figure out which item of release notes cover
> the
> > > below
> > > > feature commit
> > > > Avoid inserting Result nodes that only compute identity
> projections.
> > > > http://www.postgresql.org/message-id/E1UGCBh-0006P3-
> > > A0@gemulon.postgresql.org
> > >
> > > I did not think that warranted a mention in the release notes.  Was
> I
> > > wrong?
> >
> > This was a performance improvement for a quite usable scenario, so I
> thought
> > it would be useful for users to know about it.
> > Performance data for simple cases I have posted:
> > http://www.postgresql.org/message-
> id/007e01ce08ff$dc0a2c60$941e8520$@kapila@
> > huawei.com
> 
> I usually mention items that have a user-visible change, or are easy to
> explain, or apply to most queries.  I am not sure this falls into any
> of
> those categories.
> 
> Can you suggest some release note text for this item?

I can think of below text:

Reduce query processing overhead by avoiding insertion of useless plan nodes
OR
Improve performance of certain kind of queries by avoiding extra processing
of doing projection

This applies to queries doing identity projection ("SELECT * FROM ...") for
partitioned tables.


With Regards,
Amit Kapila.

On Thu, May 16, 2013 at 08:38:59PM +0530, Amit Kapila wrote:
> > I usually mention items that have a user-visible change, or are easy to
> > explain, or apply to most queries.  I am not sure this falls into any
> > of
> > those categories.
> > 
> > Can you suggest some release note text for this item?
> 
> I can think of below text:
> 
> Reduce query processing overhead by avoiding insertion of useless plan nodes
> OR
> Improve performance of certain kind of queries by avoiding extra processing
> of doing projection
> 
> This applies to queries doing identity projection ("SELECT * FROM ...") for
> partitioned tables.

Uh, that's pretty complex for our release notes, and hard to understand
for most users.  All they will know is that PG is faster --- we don't
document every speedup.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

"'Bruce Momjian'" <bruce@momjian.us> writes:
> On Thu, May 16, 2013 at 08:38:59PM +0530, Amit Kapila wrote:
>> Reduce query processing overhead by avoiding insertion of useless plan nodes
>> OR
>> Improve performance of certain kind of queries by avoiding extra processing
>> of doing projection
>> 
>> This applies to queries doing identity projection ("SELECT * FROM ...") for
>> partitioned tables.

> Uh, that's pretty complex for our release notes, and hard to understand
> for most users.  All they will know is that PG is faster --- we don't
> document every speedup.

No, but this is user-visible if they look at EXPLAIN output, and people
might wonder why they were getting different results.

Possibly text like
Omit unnecessary Result and Limit nodes from query plans.
        regards, tom lane

On Thu, May 16, 2013 at 06:49:33PM -0400, Tom Lane wrote:
> "'Bruce Momjian'" <bruce@momjian.us> writes:
> > On Thu, May 16, 2013 at 08:38:59PM +0530, Amit Kapila wrote:
> >> Reduce query processing overhead by avoiding insertion of useless plan nodes
> >> OR
> >> Improve performance of certain kind of queries by avoiding extra processing
> >> of doing projection
> >> 
> >> This applies to queries doing identity projection ("SELECT * FROM ...") for
> >> partitioned tables.
> 
> > Uh, that's pretty complex for our release notes, and hard to understand
> > for most users.  All they will know is that PG is faster --- we don't
> > document every speedup.
> 
> No, but this is user-visible if they look at EXPLAIN output, and people
> might wonder why they were getting different results.
> 
> Possibly text like
> 
>     Omit unnecessary Result and Limit nodes from query plans.

Yes, that would be user-visible, though we rarely add details like that.
What queries are faster, that users would understand?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Friday, May 17, 2013 4:22 AM Bruce Momjian wrote:
> On Thu, May 16, 2013 at 06:49:33PM -0400, Tom Lane wrote:
> > "'Bruce Momjian'" <bruce@momjian.us> writes:
> > > On Thu, May 16, 2013 at 08:38:59PM +0530, Amit Kapila wrote:
> > >> Reduce query processing overhead by avoiding insertion of useless
> plan nodes
> > >> OR
> > >> Improve performance of certain kind of queries by avoiding extra
> processing
> > >> of doing projection
> > >>
> > >> This applies to queries doing identity projection ("SELECT * FROM
> ...") for
> > >> partitioned tables.
> >
> > > Uh, that's pretty complex for our release notes, and hard to
> understand
> > > for most users.  All they will know is that PG is faster --- we
> don't
> > > document every speedup.
> >
> > No, but this is user-visible if they look at EXPLAIN output, and
> people
> > might wonder why they were getting different results.
> >
> > Possibly text like
> >
> >     Omit unnecessary Result and Limit nodes from query plans.
> 
> Yes, that would be user-visible, though we rarely add details like
> that.
> What queries are faster, that users would understand?

Example:
CREATE TABLE tbl_parent (c01 numeric, c02 int);                      
CREATE TABLE tbl_child () INHERITS(tbl_parent); 

INSERT INTO tbl_child (SELECT floor(random() * 10000), n FROM
generate_series(0, 10000000 - 1) n); 

SELECT * FROM tbl_parent;

Any such cases where user is selecting more number of columns from parent
table will improve a lot.

With Regards,
Amit Kapila.

On Fri, May 17, 2013 at 10:22:59AM +0530, Amit Kapila wrote:
> > Yes, that would be user-visible, though we rarely add details like
> > that.
> > What queries are faster, that users would understand?
> 
> Example:
> CREATE TABLE tbl_parent (c01 numeric, c02 int); 
>                       
> CREATE TABLE tbl_child () INHERITS(tbl_parent); 
> 
> INSERT INTO tbl_child (SELECT floor(random() * 10000), n FROM
> generate_series(0, 10000000 - 1) n); 
> 
> SELECT * FROM tbl_parent;
> 
> Any such cases where user is selecting more number of columns from parent
> table will improve a lot.

Sorry, I am still not seeing how this fits into the release notes.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

Dmitriy Igrishin escribió:

> I've noticed a small inaccuracy:
>
> E.1.3.4 Object Manipulation
> [...]
>
> "This allows C functions to be called when DDL commands are run."
>
> But according to
> http://www.postgresql.org/docs/devel/static/event-triggers.html
> not only C functions can be called in this case, but functions of
> "any procedural language that includes event trigger support, or in C".

That's correct -- at least plpgsql functions can be used.  I think PL/sh
functions can, too, so using wording that leaves out other PLs would be
inaccurate.  (No in-core languages other than plpgsql were patched, though.)

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Fri, May 17, 2013 at 10:54:25AM -0400, Alvaro Herrera wrote:
> Dmitriy Igrishin escribió:
>
> > I've noticed a small inaccuracy:
> >
> > E.1.3.4 Object Manipulation
> > [...]
> >
> > "This allows C functions to be called when DDL commands are run."
> >
> > But according to
> > http://www.postgresql.org/docs/devel/static/event-triggers.html
> > not only C functions can be called in this case, but functions of
> > "any procedural language that includes event trigger support, or in C".
>
> That's correct -- at least plpgsql functions can be used.  I think PL/sh
> functions can, too, so using wording that leaves out other PLs would be
> inaccurate.  (No in-core languages other than plpgsql were patched, though.)

Ah, very good point I had not released.  Attached release note doc patch
applied.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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