9.3 Beta1 status report

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Apr 21, 2013 at 11:06 AM, Peter Geoghegan <pg@heroku.com> 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? 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.

Yeah, HOT was always supported on the system tables in the released
versions. Early days, I tried to convince Tom that its OK to not support
HOT on system tables because updating it frequently is not that common. But
he rejected that on the grounds you explained above. Similarly, we had
other limitations such as CREATE INDEX CONCURRENTLY was broken in the early
submitted versions, but Tom insisted on getting that to work as well before
he will consider the patch. In retrospect, even though we had to burn
midnight oil to get all those limitations straight up, IMHO it made the
code more solid. Of course, Tom had a magic eye to find many corner cases,
fix them and simplify the code before committing the patch.

Andreas reported and fixed a bug which was an oversight in the FK locks
patch. I think he also discovered an old bug that the tableoid was not
being properly checked for HOT conditions but that had very limited impact
since its not common to have indexes on tableoids.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

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

------
With best regards,
Alexander Korotkov.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

Regards,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2013/4/23 Dean Rasheed <dean.a.rasheed@gmail.com>

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.

Regards,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Jov
blog: http:amutu.com/blog <http://amutu.com/blog&gt;

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

* 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 facility helps
writing such tools.

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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:
/messages/by-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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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:
/messages/by-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?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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:
/messages/by-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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 support writes.
</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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

<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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Apr 20, 2013 at 10:02 PM, 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.

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)

<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"

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

Cheers,

Jeff

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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."?

Cheers,

Jeff

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.
/messages/by-id/E1UGCBh-0006P3-A0@gemulon.postgresql.or
g

With Regards,
Amit Kapila.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.
/messages/by-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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.
/messages/by-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:
/messages/by-id/007e01ce08ff$dc0a2c60$941e8520$@kapila@
huawei.com

With Regards,
Amit Kapila.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.
/messages/by-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:
/messages/by-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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

/messages/by-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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"'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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2013/4/21 Bruce Momjian <bruce@momjian.us>

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
// Dmitriy.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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