PG 13 release notes, first draft
I have committed the first draft of the PG 13 release notes. You can
see them here:
https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Tue, 5 May 2020 at 15:16, Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Thanks a lot for putting that together.
In previous years, during the development of this you've had HTML
comments to include the commit details. Are you going to do that this
year? or did they just disappear in some compilation phase you've
done?
David
On Tue, 5 May 2020 at 16:10, David Rowley <dgrowleyml@gmail.com> wrote:
In previous years, during the development of this you've had HTML
comments to include the commit details. Are you going to do that this
year? or did they just disappear in some compilation phase you've
done?
Never mind. I just saw them all in the commit you've pushed.
David
On Tue, May 5, 2020 at 3:16 PM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Hi Bruce,
Thanks! Some feedback:
+2020-04-08 [3985b600f] Support PrefetchBuffer() in recovery.
+-->
+
+<para>
+Speedup recovery by prefetching pages (Thomas Munro)Unfortunately that commit was just an infrastructural change to allow
the PrefetchBuffer() function to work in recovery, but the main
"prefetching during recovery" patch to actually make use of it to go
faster didn't make it. So this item shouldn't be in the release
notes.
+2020-04-07 [4c04be9b0] Introduce xid8-based functions to replace txid_XXX.
+-->
+
+<para>
+Update all transaction id functions to support xid8 (Thomas Munro)
+</para>
+
+<para>
+They use the same names as the xid data type versions.
+</para>The names are actually different. How about: "New xid8-based
functions replace the txid family of functions, but the older names
are still supported for backward compatibility."
+2019-10-16 [d5ac14f9c] Use libc version as a collation version on glibc systems
+-->
+
+<para>
+Use the glibc version as the collation version (Thomas Munro)
+</para>
+
+<para>
+If the glibc version changes, a warning will be issued when a
mismatching collation is used.
+</para>I would add a qualifier "in some cases", since it doesn't work for
default collations yet. (That'll now have to wait for 14).
Hello Bruce,
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Thanks for working on this.
* Add CREATE DATABASE LOCALE option (Fabien COELHO)
* Add function gen_random_uuid to generate version 4 UUIDs (Fabien COELHO)
I'm not responsible for these, I just reviewed them. ISTM that the author
for both is the committer, Peter Eisentraut.
Maybe there is something amiss in the commit-log-to-release-notes script?
My name clearly appears after "reviewed by:?"
* "DOCUMENT THE DEFAULT GENERATION METHOD"
=> The default is still to generate data client-side.
I do not see a "documentation" section, whereas there has been significant
doc changes, such as function table layouts (Tom), glossary (Corey,
Jï¿œrgen, Roger, Alvarro), binary/text string functions (Karl) and possibly
others. Having a good documentation contributes to making postgres a very
good tool, improving it is is not very glamorous, ISTM that such
contributions should not be overlooked.
--
Fabien.
Hi
út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
There is not note about new polymorphic type "anycompatible"
Show quoted text
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com+ As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Hi,
On Tue, May 5, 2020 at 7:47 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi
út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.There is not note about new polymorphic type "anycompatible"
There's also no note about avoiding full GIN index scan
(https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4b754d6c16e16cc1a1adf12ab0f48603069a0efd).
That's a corner case optimization but it can be a huge improvement
when you hit the problem.
On Tue, May 5, 2020 at 5:16 AM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
There is one entry "Add support for collation versions on Windows" where I
am quoted as author. Actually, I was a reviewer, the author is Thomas Munro.
Also, I am credited as sole author of "Allow to_date/to_timestamp to
recognize non-English month/day names", when the case is that Tom Lane did
more than a few cosmetics changes when committing and I think he should be
quoted as co-author (if he agrees).
Regards,
Juan José Santamaría Flecha
On Mon, May 4, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
I wanted to point out there are 180 changes listed in the release notes,
which very closely matches the count of previous major releases. I
don't think there are as many major _features_ in this release as
previous ones.
Also, I see little to no progress on these features in PG 13:
* online checksum changes
* zheap
* sharding
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Hi Bruce, thanks for working on this again!
+<para>
+Allow UTF-8 escapes, e.g., E'\u####', in clients that don't use UTF-8
encoding (Tom Lane)
+</para>I believe the term we want here is "Unicode escapes". This patch is
about the server encoding, which formerly needed to be utf-8 for
non-ascii characters. (I think the client encoding doesn't matter as
long as ascii bytes are represented.)
+<para>
+The UTF-8 characters must be available in the server encoding.
+</para>Same here, s/UTF-8/Unicode/.
--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
Hello Bruce,
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Thanks for working on this.
* Add CREATE DATABASE LOCALE option (Fabien COELHO)
* Add function gen_random_uuid to generate version 4 UUIDs (Fabien COELHO)I'm not responsible for these, I just reviewed them. ISTM that the author
for both is the committer, Peter Eisentraut.Maybe there is something amiss in the commit-log-to-release-notes script?
My name clearly appears after "reviewed by:?"
Sorry, those were all my mistaken reading of the commit message.
* "DOCUMENT THE DEFAULT GENERATION METHOD"
=> The default is still to generate data client-side.
My point is that the docs are not clear about this. Can you fix it?
I do not see a "documentation" section, whereas there has been significant
doc changes, such as function table layouts (Tom), glossary (Corey, J�rgen,
I did list the glossary.
Roger, Alvarro), binary/text string functions (Karl) and possibly others.
I wasn't sure documentation _layout_ changes should be listed.
Having a good documentation contributes to making postgres a very good tool,
improving it is is not very glamorous, ISTM that such contributions should
not be overlooked.
Yes, I would be good to know from others if that kind of stuff should
be included.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 04:14:42PM +1200, Thomas Munro wrote:
On Tue, May 5, 2020 at 3:16 PM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Hi Bruce,
Thanks! Some feedback:
+2020-04-08 [3985b600f] Support PrefetchBuffer() in recovery. +--> + +<para> +Speedup recovery by prefetching pages (Thomas Munro)Unfortunately that commit was just an infrastructural change to allow
the PrefetchBuffer() function to work in recovery, but the main
"prefetching during recovery" patch to actually make use of it to go
faster didn't make it. So this item shouldn't be in the release
notes.
Agreed, removed.
+2020-04-07 [4c04be9b0] Introduce xid8-based functions to replace txid_XXX. +--> + +<para> +Update all transaction id functions to support xid8 (Thomas Munro) +</para> + +<para> +They use the same names as the xid data type versions. +</para>The names are actually different. How about: "New xid8-based
functions replace the txid family of functions, but the older names
are still supported for backward compatibility."
Agreed.
+2019-10-16 [d5ac14f9c] Use libc version as a collation version on glibc systems +--> + +<para> +Use the glibc version as the collation version (Thomas Munro) +</para> + +<para> +If the glibc version changes, a warning will be issued when a mismatching collation is used. +</para>I would add a qualifier "in some cases", since it doesn't work for
default collations yet. (That'll now have to wait for 14).
Done.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 07:46:34AM +0200, Pavel Stehule wrote:
Hi
�t 5. 5. 2020 v�5:16 odes�latel Bruce Momjian <bruce@momjian.us> napsal:
I have committed the first draft of the PG 13 release notes.� You can
see them here:� � � � https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting.� The community doc
build should happen in a few hours.There is not note about new polymorphic type "anycompatible"
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
24e2885ee304cb6a94fdfc25a1a108344ed9f4f7
Sorry I missed that. Must have thought it was non-visible work that was
part of another features. Here is the new text:
Add polymorphic data types for use by functions requiring
compatible arguments (Pavel Stehule)
The new data types are anycompatible, anycompatiblearray,
anycompatiblenonarray, and anycompatiblerange.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +út 5. 5. 2020 v 16:18 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
On Tue, May 5, 2020 at 07:46:34AM +0200, Pavel Stehule wrote:
Hi
út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.There is not note about new polymorphic type "anycompatible"
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
24e2885ee304cb6a94fdfc25a1a108344ed9f4f7Sorry I missed that. Must have thought it was non-visible work that was
part of another features. Here is the new text:Add polymorphic data types for use by functions requiring
compatible arguments (Pavel Stehule)The new data types are anycompatible, anycompatiblearray,
anycompatiblenonarray, and anycompatiblerange.
no problem, thank you
Pavel
Show quoted text
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com+ As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Tue, May 5, 2020 at 08:10:54AM +0200, Julien Rouhaud wrote:
Hi,
On Tue, May 5, 2020 at 7:47 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi
�t 5. 5. 2020 v 5:16 odes�latel Bruce Momjian <bruce@momjian.us> napsal:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.There is not note about new polymorphic type "anycompatible"
There's also no note about avoiding full GIN index scan
(https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4b754d6c16e16cc1a1adf12ab0f48603069a0efd).
That's a corner case optimization but it can be a huge improvement
when you hit the problem.
OK, I have added this item:
Allow GIN indexes to more efficiently handle NOT restrictions (Nikita
Glukhov, Alexander Korotkov, Tom Lane, Julien Rouhaud)
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 10:07:35AM +0200, Juan Jos� Santamar�a Flecha wrote:
On Tue, May 5, 2020 at 5:16 AM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes.� You can
see them here:� � � � https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting.� The community doc
build should happen in a few hours.�
There is one entry "Add support for collation versions on Windows" where I am
quoted as author. Actually, I was a reviewer, the author is Thomas Munro.
Oops, my mistake, fixed.
Also, I am credited as sole author of "Allow to_date/to_timestamp to recognize
non-English month/day names", when the case is that Tom Lane did more than a
few cosmetics changes when committing and I think he should be quoted as
co-author (if he agrees).
OK, updated. The text was:
Juan Jos� Santamar�a Flecha, reviewed and modified by me,
and with reviewed first, and the generic term modified, I had assumed
you would the the only one listed. Fixed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 09:20:39PM +0800, John Naylor wrote:
Hi Bruce, thanks for working on this again!
+<para> +Allow UTF-8 escapes, e.g., E'\u####', in clients that don't use UTF-8 encoding (Tom Lane) +</para>I believe the term we want here is "Unicode escapes". This patch is
about the server encoding, which formerly needed to be utf-8 for
non-ascii characters. (I think the client encoding doesn't matter as
long as ascii bytes are represented.)+<para> +The UTF-8 characters must be available in the server encoding. +</para>Same here, s/UTF-8/Unicode/.
OK, new text is:
Allow Unicode escapes, e.g., E'\u####', in clients that don't use UTF-8
encoding (Tom Lane)
The Unicode characters must be available in the server encoding.
I kept the "UTF-8 encoding" since that is the only Unicode encoding we
support.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On 2020-May-05, Bruce Momjian wrote:
On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
I do not see a "documentation" section, whereas there has been significant
doc changes, such as function table layouts (Tom), glossary (Corey, J�rgen,I did list the glossary.
Please do list J�rgen, Corey and Roger as authors of the glossary.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
In this item
+<listitem>
+<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2020-04-20 [5fc703946] Add ALTER .. NO DEPENDS ON
+-->
+
+<para>
+Add the ability to remove a function's dependency on an extension (Alvaro Herrera)
+</para>
+
+<para>
+The syntax is ALTER FUNCTION .. NO DEPENDS ON.
+</para>
+
+</listitem>This works for several object types, not just a functions. I propose
Add the ability to remove an object's dependency on an extension (�lvaro Herrera)
The object can be a function, materialized view, index, or trigger.
The syntax is ALTER .. NO DEPENDS ON.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-May-05, Alvaro Herrera wrote:
On 2020-May-05, Bruce Momjian wrote:
On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
I do not see a "documentation" section, whereas there has been significant
doc changes, such as function table layouts (Tom), glossary (Corey, J�rgen,I did list the glossary.
Please do list J�rgen, Corey and Roger as authors of the glossary.
(Actually I should be listed as well, as the time I spent on it was
considerable.)
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, May 5, 2020 at 11:14:11AM -0400, Alvaro Herrera wrote:
On 2020-May-05, Bruce Momjian wrote:
On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
I do not see a "documentation" section, whereas there has been significant
doc changes, such as function table layouts (Tom), glossary (Corey, J�rgen,I did list the glossary.
Please do list J�rgen, Corey and Roger as authors of the glossary.
Done, from the commit message:
Add a glossary to the documentation (Corey Huinker, J�rgen Purtz, Roger
Harkavy, �lvaro Herrera)
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 11:23:50AM -0400, Alvaro Herrera wrote:
On 2020-May-05, Alvaro Herrera wrote:
On 2020-May-05, Bruce Momjian wrote:
On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
I do not see a "documentation" section, whereas there has been significant
doc changes, such as function table layouts (Tom), glossary (Corey, J�rgen,I did list the glossary.
Please do list J�rgen, Corey and Roger as authors of the glossary.
(Actually I should be listed as well, as the time I spent on it was
considerable.)
Yep, already done, based on the commit text. :-)
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On 5/4/20 11:16 PM, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Peter Eisentraut gets the credit for Unix domain sockets on Windows, not
me, I just reviewed it.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, May 5, 2020 at 11:48:47AM -0400, Andrew Dunstan wrote:
On 5/4/20 11:16 PM, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Peter Eisentraut gets the credit for Unix domain sockets on Windows, not
me, I just reviewed it.
Sorry about that, fixed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Please do list Jürgen, Corey and Roger as authors of the glossary.
(Actually I should be listed as well, as the time I spent on it was
considerable.)
+1, the time spent was quite considerable
|Release date: 2020-05-03
=> Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight.
|These triggers cannot change the destination partition.
=> Maybe say "cannot change which partition is the destination"
|Allow incremental sorting (James Coleman, Alexander Korotkov)
s/Allow/Implement/ ?
|If a result is already sorted by several keys,
s/keys/leading keys/
| Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis)
| Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is controlled by enable_hashagg_disk.
=> enable_hashagg_disk doesn't behave like other enable_* parameters.
As I understand, disabling it only "opportunisitically" avoids plans which are
*expected* to overflow work_mem. I think we should specifically say that, and
maybe suggest recalibrating work_mem.
|This new behavior sets pages as all-visible
I think it should say "can allow setting pages all-visible"
It doesn't do anything special to force anything to be allvisible.
| This is controlled by GUC wal_skip_threshold.
I think you should say that's a size threshold which determines which strategy
to use (WAL or fsync).
| Improve the performance of replay of DROP DATABASE commands that use many tablespaces (Fujii Masao)
"when replaying DROP DATABASE commands if many tablespaces are in use"
|Improve performance for truncation of very larger relations (Kirk Jamison)
*large
|Server variable backtrace_functions specifies which C functions should generate backtraces on error.
Could you say "GUC" so it's easy to search for ?
| This is controlled by ssl_min_protocol_version.
| This behavior can be enabled using wal_receiver_create_temp_slot.
| This is controlled by logical_decoding_work_mem.
| This is enabled using ignore_invalid_pages.
Say GUC in these places, too ?
|Previously, server restart was required to change primary_conninfo and primary_slot_name.
*a* server restart
| Speedup recovery by prefetching pages (Thomas Munro)
"Speed up" or accelerate or "Improve speed of".
Speedup (one word) sounds like a noun.
| Fix bugs in ALTER TABLE where later clauses overlap changes made by earlier clauses in the same command (Tom Lane)
s/where/when/ ?
| The new function, jsonb_set_lax(), allows null new values to either set the specified key to JSON null, delete the key, raise exception, or ignore operation. IS 'return_target' CLEAR?
ignore *the* operation
| time zone-aware output.
timezone-aware ?
| This makes \gx equivalent to \g (expanded=on).
I would say: "this allows syntax like \g (expand=on) which is equivalent to \gx"
|Allow pgbench to partition its 'accounts' table (Fabien COELHO)
Sometimes Fabien's name is/not capitalized.
| This is enable using the -c/--restore-target-wal option.
*enabled*
| These long-supported options for this are called --superuser and --no-superuser.
"The supported" not "These long-supported" ?
I'm not sure, but maybe these patches of mine should be documented?
commit 24f62e93f314c107b4fa679869e5ba9adb2d545f
Improve psql's \d output for partitioned indexes.
commit c33869cc3bfc42bce822251f2fa1a2a346f86cc5
psql \d: Display table where trigger is defined, if inherited
=> Alvaro said the functionality could conceivably be backpatched
(nontrivially), which suggests this doesn't need to be documented, but I think
backpatch would be a bad idea, and I think it should be documented.
--
Justin
On Tue, May 5, 2020 at 11:45:03AM -0500, Justin Pryzby wrote:
|Release date: 2020-05-03
=> Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight.
Agreed!
|These triggers cannot change the destination partition.
=> Maybe say "cannot change which partition is the destination"|Allow incremental sorting (James Coleman, Alexander Korotkov)
s/Allow/Implement/ ?
Agreed.
|If a result is already sorted by several keys,
s/keys/leading keys/
Agreed.
| Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis)
| Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is controlled by enable_hashagg_disk.
=> enable_hashagg_disk doesn't behave like other enable_* parameters.
As I understand, disabling it only "opportunisitically" avoids plans which are
*expected* to overflow work_mem. I think we should specifically say that, and
maybe suggest recalibrating work_mem.
I went with "avoided":
Previously, hash aggregation was avoided if it was expected to use more
than work_mem memory. This is controlled by enable_hashagg_disk.
|This new behavior sets pages as all-visible
I think it should say "can allow setting pages all-visible"
It doesn't do anything special to force anything to be allvisible.
OK, updated to:
This new behavior allows pages to be set as all-visible, which then
allows index-only scans, and reduces the work necessary when the table
needs to be frozen.
| This is controlled by GUC wal_skip_threshold.
I think you should say that's a size threshold which determines which strategy
to use (WAL or fsync).
I went with:
The WAL write amount where this happens is controlled by wal_skip_threshold.
They can use the doc link if they want more detail.
| Improve the performance of replay of DROP DATABASE commands that use many tablespaces (Fujii Masao)
"when replaying DROP DATABASE commands if many tablespaces are in use"
OK, updated to:
Improve the performance when replaying DROP DATABASE commands when many
tablespaces are in use (Fujii Masao)
|Improve performance for truncation of very larger relations (Kirk Jamison)
*large
Fixed.
|Server variable backtrace_functions specifies which C functions should generate backtraces on error.
Could you say "GUC" so it's easy to search for ?
Uh, I kind of back and forth on whether GUC or server variable is
better. I kind of mix them up so people will know what GUC is.
| This is controlled by ssl_min_protocol_version.
| This behavior can be enabled using wal_receiver_create_temp_slot.
| This is controlled by logical_decoding_work_mem.
| This is enabled using ignore_invalid_pages.
Say GUC in these places, too ?
Oh, uh, I am not sure. These will all have links too.
|Previously, server restart was required to change primary_conninfo and primary_slot_name.
*a* server restart
Agreed.
| Speedup recovery by prefetching pages (Thomas Munro)
"Speed up" or accelerate or "Improve speed of".
Speedup (one word) sounds like a noun.
Uh, someone requested I remove that, so I have.
| Fix bugs in ALTER TABLE where later clauses overlap changes made by earlier clauses in the same command (Tom Lane)
s/where/when/ ?
Agreed.
| The new function, jsonb_set_lax(), allows null new values to either set the specified key to JSON null, delete the key, raise exception, or ignore operation. IS 'return_target' CLEAR?
ignore *the* operation
Agreed.
| time zone-aware output.
timezone-aware ?
Uh, time zone is two words. We can do time-zone-aware but that looks
odd.
| This makes \gx equivalent to \g (expanded=on).
I would say: "this allows syntax like \g (expand=on) which is equivalent to \gx"
I like that.
|Allow pgbench to partition its 'accounts' table (Fabien COELHO)
Sometimes Fabien's name is/not capitalized.
I have already committed a fix for that.
| This is enable using the -c/--restore-target-wal option.
*enabled*
Agreed.
| These long-supported options for this are called --superuser and --no-superuser.
"The supported" not "These long-supported" ?
Yep.
I'm not sure, but maybe these patches of mine should be documented?
commit 24f62e93f314c107b4fa679869e5ba9adb2d545f
Improve psql's \d output for partitioned indexes.commit c33869cc3bfc42bce822251f2fa1a2a346f86cc5
psql \d: Display table where trigger is defined, if inherited=> Alvaro said the functionality could conceivably be backpatched
(nontrivially), which suggests this doesn't need to be documented, but I think
backpatch would be a bad idea, and I think it should be documented.
I looked at these and they looked like incremental changes to psql
display in a way that people would say "nice", but not really want to
know about it before-hand. Maybe I am wrong.
Thanks for all your fixes, all committed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 05, 2020 at 01:18:09PM -0400, Bruce Momjian wrote:
|Release date: 2020-05-03
=> Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight.Agreed!
|These triggers cannot change the destination partition.
=> Maybe say "cannot change which partition is the destination"
Looks like you copied my quote mark :(
| Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis)
| Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is controlled by enable_hashagg_disk.
=> enable_hashagg_disk doesn't behave like other enable_* parameters.
As I understand, disabling it only "opportunisitically" avoids plans which are
*expected* to overflow work_mem. I think we should specifically say that, and
maybe suggest recalibrating work_mem.I went with "avoided":
Previously, hash aggregation was avoided if it was expected to use more
than work_mem memory. This is controlled by enable_hashagg_disk.
I think we should expand on this:
|Previously, hash aggregation was avoided if it was expected to use more than
|work_mem memory, but it wasn't enforced, and hashing could still exceed
|work_mem. To get back the old behavior, increasing work_mem.
|
|The parameter enable_hashagg_disk controls whether a plan which is *expected*
|to spill to disk will be considered. During execution, an aggregate node which
|exceeding work_mem will spill to disk regardless of this parameter.
I wrote something similar here:
/messages/by-id/20200407223900.GT2228@telsasoft.com
| This is controlled by GUC wal_skip_threshold.
I think you should say that's a size threshold which determines which strategy
to use (WAL or fsync).I went with:
The WAL write amount where this happens is controlled by wal_skip_threshold.They can use the doc link if they want more detail.
I guess I would say "relations larger than wal_skip_threshold will be fsynced
rather than copied to WAL"
--
Justin
Do you want to include any of these?
5823677acc Provide pgbench --show-script to dump built-in scripts.
ce8f946764 Report the time taken by pgbench initialization steps.
751c63cea0 Remove pg_regress' --load-language option.
33753ac9d7 Add object names to partition integrity violations.
246f136e76 Improve handling of parameter differences in physical replication
a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
2fc2a88e67 Remove obsolete information schema tables
b9b408c487 Record parents of triggers (tgparentid)
2b2bacdca0 Reset statement_timeout between queries of a multi-query string.
09f08930f0 initdb: Change authentication defaults Change the defaults for the pg_hba.conf generated by initdb to "peer" or "md5"
Improve control of prepared statement parameter logging
The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement logging, and log_parameter_max_length_on_error allows parameters to be output on
I think the original commit (ba79cb5d) gets lost in the description of the
details and the following commit. I would say:
|Emit parameter values during query bind/execute errors and allow control of the max length logged by statement logging (Alexey Bashtanov, �lvaro Herrera)
|The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement logging, and log_parameter_max_length_on_error allows parameters to be output on
|error.
Or maybe split that into two items.
Allow track_activity_query_size to be set to 1MB (Vyacheslav Makarov)
Say "*up* to 1MB".
super users
say "superuser" ?
Allow allow_system_table_mods to be changed after server start (Peter Eisentraut)
Disallow non-super users from modifying system tables when allow_system_table_mods is set (Peter Eisentraut)
I think these two entries can be merged.
Add parallel control of the vacuumdb command using --parallel (Masahiko Sawada)
Allow reindexdb to operate in parallel (Julien Rouhaud)
Parallel mode is enabled with the new --jobs option.
It's probably worth saying that vacuumdb --parallel just passes (parallel N)
option to the vacuum command, which means that it processes indexes in parallel.
Whereas reindexdb --jobs is a client-side feature, creating a separate sessions
for each.
--
Justin
On Tue, May 5, 2020 at 12:50:01PM -0500, Justin Pryzby wrote:
On Tue, May 05, 2020 at 01:18:09PM -0400, Bruce Momjian wrote:
|Release date: 2020-05-03
=> Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight.Agreed!
|These triggers cannot change the destination partition.
=> Maybe say "cannot change which partition is the destination"Looks like you copied my quote mark :(
I kind of liked it, but OK, removed. ;-)
| Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis)
| Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is controlled by enable_hashagg_disk.
=> enable_hashagg_disk doesn't behave like other enable_* parameters.
As I understand, disabling it only "opportunisitically" avoids plans which are
*expected* to overflow work_mem. I think we should specifically say that, and
maybe suggest recalibrating work_mem.I went with "avoided":
Previously, hash aggregation was avoided if it was expected to use more
than work_mem memory. This is controlled by enable_hashagg_disk.I think we should expand on this:
|Previously, hash aggregation was avoided if it was expected to use more than
|work_mem memory, but it wasn't enforced, and hashing could still exceed
|work_mem. To get back the old behavior, increasing work_mem.
I think work_mem has too many other effects to recommend just changing
it for this.
|The parameter enable_hashagg_disk controls whether a plan which is *expected*
|to spill to disk will be considered. During execution, an aggregate node which
|exceeding work_mem will spill to disk regardless of this parameter.I wrote something similar here:
/messages/by-id/20200407223900.GT2228@telsasoft.com
I think this kind of information should be in our docs, not really the
release notes.
| This is controlled by GUC wal_skip_threshold.
I think you should say that's a size threshold which determines which strategy
to use (WAL or fsync).I went with:
The WAL write amount where this happens is controlled by wal_skip_threshold.They can use the doc link if they want more detail.
I guess I would say "relations larger than wal_skip_threshold will be fsynced
rather than copied to WAL"
How is this?
Relations larger than wal_skip_threshold will have their files fynsced
rather than writing their WAL records.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
Do you want to include any of these?
5823677acc Provide pgbench --show-script to dump built-in scripts.
ce8f946764 Report the time taken by pgbench initialization steps.
I am kind of unclear how much of pgbench changes to put in the release
notes since the use seems so specialized, but maybe that is wrong.
751c63cea0 Remove pg_regress' --load-language option.
Well, for the same reasons, that is our regression tests, which I assume
is more for internal use.
33753ac9d7 Add object names to partition integrity violations.
Improving error messages is not something I usually cover. People like
to see the better error messages, but don't really value knowing about
them before-hand, I am guessing.
246f136e76 Improve handling of parameter differences in physical replication
That seems to fall in the category above.
a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
Uh, that didn't seem significant.
2fc2a88e67 Remove obsolete information schema tables
b9b408c487 Record parents of triggers (tgparentid)
2b2bacdca0 Reset statement_timeout between queries of a multi-query string.
That seemed like a bug fix for unusual usage.
09f08930f0 initdb: Change authentication defaults Change the defaults for the pg_hba.conf generated by initdb to "peer" or "md5"
Uh, that was reverted:
Author: Peter Eisentraut <peter@eisentraut.org>
2019-07-22 [796188658] Revert "initdb: Change authentication defaults"
Revert "initdb: Change authentication defaults"
This reverts commit 09f08930f0f6fd4a7350ac02f29124b919727198.
The buildfarm client needs some adjustments first.
Improve control of prepared statement parameter logging
The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement logging, and log_parameter_max_length_on_error allows parameters to be output onI think the original commit (ba79cb5d) gets lost in the description of the
details and the following commit. I would say:
|Emit parameter values during query bind/execute errors and allow control of the max length logged by statement logging (Alexey Bashtanov, �lvaro Herrera)
|The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement logging, and log_parameter_max_length_on_error allows parameters to be output on
|error.
Or maybe split that into two items.
I struggled on this one because we are both limiting parameter length
when logging of normal queries _and_ adding paramater logging of error
queries, also with a length limit.
I tried a few approaches but ended up with this:
Improve control of prepared statement parameter logging (Alexey
Bashtanov, Álvaro Herrera)
The GUC setting log_parameter_max_length controls the maximum
length of parameter values output during statement non-error
logging, and log_parameter_max_length_on_error does the same
for error statement logging. Previously, prepared statement
parameters were not logged during errors.
Allow track_activity_query_size to be set to 1MB (Vyacheslav Makarov)
Say "*up* to 1MB".
Agreed.
super users
say "superuser" ?
All fixed, thanks.
Allow allow_system_table_mods to be changed after server start (Peter Eisentraut)
Disallow non-super users from modifying system tables when allow_system_table_mods is set (Peter Eisentraut)I think these two entries can be merged.
Uh, they are quite different. The first one is about not requiring a
reboot, while the second is a fix for allowing users do things when it
is set that they should not be able to do.
Add parallel control of the vacuumdb command using --parallel (Masahiko Sawada)
Allow reindexdb to operate in parallel (Julien Rouhaud)
Parallel mode is enabled with the new --jobs option.It's probably worth saying that vacuumdb --parallel just passes (parallel N)
option to the vacuum command, which means that it processes indexes in parallel.
Whereas reindexdb --jobs is a client-side feature, creating a separate sessions
for each.
Oh, wow, good point, and very subtle. I used this text:
Allow vacuum commands run by vacuumdb to operate in parallel mode
(Masahiko Sawada)
This is enabled with the new --parallel option.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Mon, 2020-05-04 at 23:16 -0400, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Regarding grouping sets:
Just like hash aggregation, grouping sets could exceed work_mem by
large amounts in v12. Now, in v13, they both use disk when appropriate.
There's an open item where we will consider tweaking the GUCs, so the
descriptions might change slightly.
Regards,
Jeff Davis
On Tue, May 05, 2020 at 02:10:24PM -0400, Bruce Momjian wrote:
| This is controlled by GUC wal_skip_threshold.
I think you should say that's a size threshold which determines which strategy
to use (WAL or fsync).I went with:
The WAL write amount where this happens is controlled by wal_skip_threshold.They can use the doc link if they want more detail.
I guess I would say "relations larger than wal_skip_threshold will be fsynced
rather than copied to WAL"How is this?
Relations larger than wal_skip_threshold will have their files fynsced
rather than writing their WAL records.
I see I was too late, but:
Fix typo (fynsc) and maybe add parens().
--
Justin
On 2020-May-05, Bruce Momjian wrote:
|Allow incremental sorting (James Coleman, Alexander Korotkov)
s/Allow/Implement/ ?Agreed.
FWIW I think Tomas Vondra should be credited as coauthor of this
feature. He didn't list himself as author in the commit message but I'm
pretty sure that's out of modesty, not lack of contribution.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-May-05, Bruce Momjian wrote:
On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
Do you want to include any of these?
5823677acc Provide pgbench --show-script to dump built-in scripts.
ce8f946764 Report the time taken by pgbench initialization steps.I am kind of unclear how much of pgbench changes to put in the release
notes since the use seems so specialized, but maybe that is wrong.
Maybe it would make sense to group all pgbench changes in a subsection
of their own?
a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
2fc2a88e67 Remove obsolete information schema tablesUh, that didn't seem significant.
Maybe have one item "modernize information_schema", and then describe
all the changes together in a single item.
I tried a few approaches but ended up with this:
Improve control of prepared statement parameter logging (Alexey
Bashtanov, Álvaro Herrera)The GUC setting log_parameter_max_length controls the maximum
length of parameter values output during statement non-error
logging, and log_parameter_max_length_on_error does the same
for error statement logging. Previously, prepared statement
parameters were not logged during errors.
This seems good to me. I think Tom Lane should be listed as coauthor of
this item.
I used this text:
Allow vacuum commands run by vacuumdb to operate in parallel mode
(Masahiko Sawada)This is enabled with the new --parallel option.
I think the vacuumdb item should be merged with the item for 40d964ec9,
since this is just about vacuumdb gaining control of the new VACUUM
feature. It's not something you can use separately from that.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 5/5/20 3:21 PM, Alvaro Herrera wrote:
On 2020-May-05, Bruce Momjian wrote:
|Allow incremental sorting (James Coleman, Alexander Korotkov)
s/Allow/Implement/ ?Agreed.
FWIW I think Tomas Vondra should be credited as coauthor of this
feature. He didn't list himself as author in the commit message but I'm
pretty sure that's out of modesty, not lack of contribution.
+1.
--
-David
david@pgmasters.net
On Tue, May 05, 2020 at 03:44:37PM -0400, Alvaro Herrera wrote:
On 2020-May-05, Bruce Momjian wrote:
On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
Do you want to include any of these?
5823677acc Provide pgbench --show-script to dump built-in scripts.
ce8f946764 Report the time taken by pgbench initialization steps.I am kind of unclear how much of pgbench changes to put in the release
notes since the use seems so specialized, but maybe that is wrong.Maybe it would make sense to group all pgbench changes in a subsection
of their own?a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
2fc2a88e67 Remove obsolete information schema tablesUh, that didn't seem significant.
Maybe have one item "modernize information_schema", and then describe
all the changes together in a single item.
FYI, I did the same as last year, so I found these from output of something
like git log --cherry-pick REL_12_STABLE...master
I asked to avoid false negatives, not because I specifically want those commits
mentioned.
I used this text:
Allow vacuum commands run by vacuumdb to operate in parallel mode
(Masahiko Sawada)This is enabled with the new --parallel option.
I think the vacuumdb item should be merged with the item for 40d964ec9,
since this is just about vacuumdb gaining control of the new VACUUM
feature. It's not something you can use separately from that.
+1
--
Justin
On Tue, May 5, 2020 at 11:44:33AM -0700, Jeff Davis wrote:
On Mon, 2020-05-04 at 23:16 -0400, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Regarding grouping sets:
Just like hash aggregation, grouping sets could exceed work_mem by
large amounts in v12. Now, in v13, they both use disk when appropriate.
Oh, another place I should change "not used" to "avoided". Thanks.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 01:45:37PM -0500, Justin Pryzby wrote:
On Tue, May 05, 2020 at 02:10:24PM -0400, Bruce Momjian wrote:
| This is controlled by GUC wal_skip_threshold.
I think you should say that's a size threshold which determines which strategy
to use (WAL or fsync).I went with:
The WAL write amount where this happens is controlled by wal_skip_threshold.They can use the doc link if they want more detail.
I guess I would say "relations larger than wal_skip_threshold will be fsynced
rather than copied to WAL"How is this?
Relations larger than wal_skip_threshold will have their files fynsced
rather than writing their WAL records.I see I was too late, but:
Fix typo (fynsc) and maybe add parens().
Ah, I was looking for fsync to fix that and could not find it. Now I
found it with that spelling, I ended up using "fsync'ed".
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 03:21:00PM -0400, Alvaro Herrera wrote:
On 2020-May-05, Bruce Momjian wrote:
|Allow incremental sorting (James Coleman, Alexander Korotkov)
s/Allow/Implement/ ?Agreed.
FWIW I think Tomas Vondra should be credited as coauthor of this
feature. He didn't list himself as author in the commit message but I'm
pretty sure that's out of modesty, not lack of contribution.
Thanks, added. We will hunt that modesty down! LOL
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 03:44:37PM -0400, Alvaro Herrera wrote:
On 2020-May-05, Bruce Momjian wrote:
On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
Do you want to include any of these?
5823677acc Provide pgbench --show-script to dump built-in scripts.
ce8f946764 Report the time taken by pgbench initialization steps.I am kind of unclear how much of pgbench changes to put in the release
notes since the use seems so specialized, but maybe that is wrong.Maybe it would make sense to group all pgbench changes in a subsection
of their own?
pgbench already has its own section in the docs:
E.1.3.8.2. pgbench
I would be glad to expand it since it is easy to pick out pgbench items
from the commit logs.
a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
2fc2a88e67 Remove obsolete information schema tablesUh, that didn't seem significant.
Maybe have one item "modernize information_schema", and then describe
all the changes together in a single item.
Uh, so I am unclear when we are adding items to information_schema
because we now support them, and when they are new features of
information_schema.
I tried a few approaches but ended up with this:
Improve control of prepared statement parameter logging (Alexey
Bashtanov, Álvaro Herrera)The GUC setting log_parameter_max_length controls the maximum
length of parameter values output during statement non-error
logging, and log_parameter_max_length_on_error does the same
for error statement logging. Previously, prepared statement
parameters were not logged during errors.This seems good to me. I think Tom Lane should be listed as coauthor of
this item.
Added.
I used this text:
Allow vacuum commands run by vacuumdb to operate in parallel mode
(Masahiko Sawada)This is enabled with the new --parallel option.
I think the vacuumdb item should be merged with the item for 40d964ec9,
since this is just about vacuumdb gaining control of the new VACUUM
feature. It's not something you can use separately from that.
Well, it is under Server Commands and has a new flag, so I thought it
should be here.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
On 2020-May-05, Bruce Momjian wrote:
I tried a few approaches but ended up with this:
Improve control of prepared statement parameter logging (Alexey
Bashtanov, Álvaro Herrera)The GUC setting log_parameter_max_length controls the maximum
length of parameter values output during statement non-error
logging, and log_parameter_max_length_on_error does the same
for error statement logging. Previously, prepared statement
parameters were not logged during errors.
This seems good to me. I think Tom Lane should be listed as coauthor of
this item.
Not necessary, I didn't do much on that.
regards, tom lane
On Tue, May 5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote:
On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
Do you want to include any of these?
5823677acc Provide pgbench --show-script to dump built-in scripts.
I have added the above entry to the release notes.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 5, 2020 at 05:31:26PM -0400, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
On 2020-May-05, Bruce Momjian wrote:
I tried a few approaches but ended up with this:
Improve control of prepared statement parameter logging (Alexey
Bashtanov, Álvaro Herrera)The GUC setting log_parameter_max_length controls the maximum
length of parameter values output during statement non-error
logging, and log_parameter_max_length_on_error does the same
for error statement logging. Previously, prepared statement
parameters were not logged during errors.This seems good to me. I think Tom Lane should be listed as coauthor of
this item.Not necessary, I didn't do much on that.
OK, removed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 05, 2020 at 05:34:26PM -0400, Bruce Momjian wrote:
On Tue, May 5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote:
On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
Do you want to include any of these?
5823677acc Provide pgbench --show-script to dump built-in scripts.
I have added the above entry to the release notes.
+2019-07-16 [ce8f94676] Report the time taken by pgbench initialization steps.
+Allow pgbench to dump script contents using --show-script (Fabien Coelho)I think you confused these?
ce8f946764 Report the time taken by pgbench initialization steps.
5823677acc Provide pgbench --show-script to dump built-in scripts.
--
Justin
On Tue, May 5, 2020 at 04:39:58PM -0500, Justin Pryzby wrote:
On Tue, May 05, 2020 at 05:34:26PM -0400, Bruce Momjian wrote:
On Tue, May 5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote:
On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
Do you want to include any of these?
5823677acc Provide pgbench --show-script to dump built-in scripts.
I have added the above entry to the release notes.
+2019-07-16 [ce8f94676] Report the time taken by pgbench initialization steps. +Allow pgbench to dump script contents using --show-script (Fabien Coelho)I think you confused these?
ce8f946764 Report the time taken by pgbench initialization steps.
5823677acc Provide pgbench --show-script to dump built-in scripts.
You are correct, fixed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Hello Bruce,
* "DOCUMENT THE DEFAULT GENERATION METHOD"
=> The default is still to generate data client-side.My point is that the docs are not clear about this.
Indeed.
Can you fix it?
Sure. Attached patch adds an explicit sentence about it, as it was only
hinted about in the default initialization command string, and removes a
spurious empty paragraph found nearby.
--
Fabien.
Attachments:
pgbench-doc-default-g-1.patchtext/x-diff; name=pgbench-doc-default-g-1.patchDownload
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index c9a9f0e0e5..ef75e5328c 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -198,6 +198,8 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
<para>
Generate data and load it into the standard tables,
replacing any data already present.
+ Default is to generate data client-side (<literal>g</literal>)
+ and transmit it over the connection.
</para>
<para>
With <literal>g</literal> (client-side data generation),
@@ -218,9 +220,6 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
message when generating data into
<structname>pgbench_accounts</structname> table.
</para>
- <para>
-
- </para>
</listitem>
</varlistentry>
<varlistentry>
5 мая 2020 г., в 08:16, Bruce Momjian <bruce@momjian.us> написал(а):
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything pglz-compressed) decompression should be significantly faster in v13.
https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06
Best regards, Andrey Borodin.
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
Kyotaro Horiguchi authored that one. (I committed it.) The commit message
noted characteristics, some of which may deserve mention in the notes:
- Crash recovery was losing tuples written via COPY TO. This fixes the bug.
- Out-of-tree table access methods will require changes.
- Users setting a timeout on COMMIT may need to adjust that timeout, and
log_min_duration_statement analysis will reflect time consumption moving to
COMMIT from commands like COPY.
- COPY has worked this way for awhile; this extends it to all modifications.
On Tue, May 5, 2020 at 6:16 AM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:
Great, thank you!
It seems that opclass parameters (911e702077) are not reflected in the
release notes.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi Bruce,
On Tue, May 5, 2020 at 12:16 PM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Thanks for this as always.
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2019-08-07 [4e85642d9] Apply constraint exclusion more generally in partitionin
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2019-08-13 [815ef2f56] Don't constraint-exclude partitioned tables as much
+-->
+
+<para>
+Improve cases where pruning of partitions can happen (Amit Langote,
Yuzuko Hosoya, Álvaro Herrera)
+</para>The following commit should be included with this item:
commit 489247b0e615592111226297a0564e11616361a5
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Sun Aug 4 11:18:45 2019 -0400
Improve pruning of a default partition
Primary author for this commit and the person who raised various
problems that led to these improvements is Yuzuko Hosoya. So I think
her name should go first.
+Author: Etsuro Fujita <efujita@postgresql.org>
+2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN
+-->
+
+<para>
+Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
Etsuro Fujita, Amit Langote)
+</para>Maybe it would be better to break this into two items, because while
c8434d64c is significant new functionality that I only contributed a
few review comments towards, 981643dcd is relatively minor surgery of
partitionwise join code to handle FULL JOINs correctly. Tom's rewrite
of my patch for the latter was pretty significant too, so maybe better
to list his name as well.
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
+-->
+
+<para>
+Allow logical replication to replicate partitioned tables (Amit Langote)
+</para>
+
+</listitem>
+
+<listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
+-->
+
+<para>
+Allow partitioned tables to be added to replicated publications (Amit Langote)
+</para>
+
+<para>
+Partition additions/removals are replicated as well. Previously,
partitions had to be replicated individually. HOW IS THIS DIFFERENT
FROM THE ITEM ABOVE?
+</para>The former is subscription-side new functionality and the latter is
publication-side and the two are somewhat independent.
Till now, logical replication could only occur between relkind 'r'
relations. So the only way to keep a given partitioned table in sync
on the two servers was to manually add the leaf partitions (of relkind
'r') to a publication and also manually keep the list of replicated
tables up to date as partitions come and go, that is, by
adding/removing them to/from the publication.
17b9e7f9f (the second item) makes it possible for the partitioned
table (relkind 'p') to be added to the publication so that individual
leaf partitions need not be manually kept in the publication.
Replication still flows between the leaf partitions (relkind 'r'
relations) though.
f1ac27bfd (the first item) makes is possible to replicate from a
regular table (relkind 'r') into a partitioned table (relkind 'p').
If a given row is replicated into a partitioned table, the
subscription worker will route it to the correct leaf partition of
that partitioned table.
+<listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
+-->
+
+<para>
+Allow CREATE PUBLICATION to control whether partitioned tables are
published as themselves or their ancestors (Amit Langote)
+</para>
+
+<para>
+The option is publish_via_partition_root.
+</para>And this allows replication to optionally originate from relkind 'p'
relations on the publication server, whereas it could previously only
originate from relkind 'r' relations. Combined with the first item,
users can now replicate between partitioned tables that have a
different set of partitions on the two servers.
Maybe it would make sense to combine the three into one item:
<para>
Add support for logical replication of partitioned tables
</para>
<para>
Logical replication can now occur between partitioned tables, where
previously it would only be allowed between regular tables. A new
publication option <literal>publish_via_partition_root</literal>
controls whether a leaf partition's changes are published as its own
or as that of the ancestor that's actually published.
</para>
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
On 05/05/20 10:31, Bruce Momjian wrote:
On Tue, May 5, 2020 at 09:20:39PM +0800, John Naylor wrote:
... This patch is
about the server encoding, which formerly needed to be utf-8 for
non-ascii characters. (I think the client encoding doesn't matter as
long as ascii bytes are represented.)+<para> +The UTF-8 characters must be available in the server encoding. +</para>Same here, s/UTF-8/Unicode/.
OK, new text is:
Allow Unicode escapes, e.g., E'\u####', in clients that don't use UTF-8
encoding (Tom Lane)The Unicode characters must be available in the server encoding.
I kept the "UTF-8 encoding" since that is the only Unicode encoding we
support.
My understanding also was that it matters little to this change what the
/client's/ encoding is.
There used to be a limitation of the server's lexer that would reject
Unicode escapes whenever the /server's/ encoding wasn't UTF-8 (even
if the server's encoding contained the characters the escapes represent).
I think that limitation is what was removed.
I don't think the client encoding comes into it at all. Sure, you could
just include the characters literally if they are in the client encoding,
but you might still choose to express them as escapes, and if you do they
get passed that way to the server for interpretation.
I had assumed the patch applied to all of the forms U&'\####',
U&'\+######', E'\u####', and E'\U######' but I don't think I read
the patch to be sure of that.
Regards,
-Chap
On 05/06/20 16:01, Chapman Flack wrote:
I had assumed the patch applied to all of the forms U&'\####',
U&'\+######', E'\u####', and E'\U######' ...
annnd that last form needs to have eight #s. (Can't be respelled with 4 ♭s.)
-Chap
On Wed, May 6, 2020 at 07:36:21AM +0200, Fabien COELHO wrote:
Hello Bruce,
* "DOCUMENT THE DEFAULT GENERATION METHOD"
=> The default is still to generate data client-side.My point is that the docs are not clear about this.
Indeed.
Can you fix it?
Sure. Attached patch adds an explicit sentence about it, as it was only
hinted about in the default initialization command string, and removes a
spurious empty paragraph found nearby.
Thanks, patch applied.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
5 мая 2020 г., в 08:16, Bruce Momjian <bruce@momjian.us> написал(а):
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything pglz-compressed) decompression should be significantly faster in v13.
https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06
OK, I read the thread mentioned in the commit message and I now see the
value of this change. Attached is the release note diff. Let me know
if it needs improvement.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Attachments:
toast.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 7232366080..2ec8bb2748 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -675,7 +675,7 @@ Author: Tomas Vondra <tomas.vondra@postgresql.org>
-->
<para>
-Improve retrieving of only the leading bytes of TOAST values (Binguo Bao)
+Improve speed of TOAST decompression and the retrievel of only the leading bytes of TOAST values (Binguo Bao, Andrey Borodin)
</para>
<para>
On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
Kyotaro Horiguchi authored that one. (I committed it.) The commit message
noted characteristics, some of which may deserve mention in the notes:
Fixed.
- Crash recovery was losing tuples written via COPY TO. This fixes the bug.
This was not backpatched?
- Out-of-tree table access methods will require changes.
Uh, I don't think we mention those.
- Users setting a timeout on COMMIT may need to adjust that timeout, and
log_min_duration_statement analysis will reflect time consumption moving to
COMMIT from commands like COPY.
Uh, not sure how to say that but I don't think we would normally mention that.
- COPY has worked this way for awhile; this extends it to all modifications.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Wed, May 6, 2020 at 03:18:54PM +0300, Alexander Korotkov wrote:
On Tue, May 5, 2020 at 6:16 AM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:Great, thank you!
It seems that opclass parameters (911e702077) are not reflected in the
release notes.
Uh, I have these items, just not that commit id:
<listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2020-03-30 [911e70207] Implement operator class parameters
-->
<para>
Allow index operator classes to take parameters (Nikita Glukhov)
</para>
</listitem>
<listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2020-03-30 [911e70207] Implement operator class parameters
-->
<para>
Allow CREATE INDEX to specify the GiST signature length and maximum number of integer ranges (Nikita Glukhov)
</para>
</listitem>
Is that OK?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Wed, May 06, 2020 at 07:35:34PM -0400, Bruce Momjian wrote:
On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything pglz-compressed) decompression should be significantly faster in v13.
https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06OK, I read the thread mentioned in the commit message and I now see the
value of this change. Attached is the release note diff. Let me know
if it needs improvement.
Sorry I didn't see it earlier, but:
-Improve retrieving of only the leading bytes of TOAST values (Binguo Bao) +Improve speed of TOAST decompression and the retrievel of only the leading bytes of TOAST values (Binguo Bao, Andrey Borodin)
retrieval
I will include this with my running doc patch if you don't want to make a
separate commit.
--
Justin
On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
Kyotaro Horiguchi authored that one. (I committed it.) The commit message
noted characteristics, some of which may deserve mention in the notes:Fixed.
I don't see that change pushed (but it's not urgent).
- Crash recovery was losing tuples written via COPY TO. This fixes the bug.
This was not backpatched?
Right.
- Out-of-tree table access methods will require changes.
Uh, I don't think we mention those.
Okay. This point is relatively-important. On the other hand, the table
access methods known to me have maintainers who follow -hackers. They may
learn that way.
- Users setting a timeout on COMMIT may need to adjust that timeout, and
log_min_duration_statement analysis will reflect time consumption moving to
COMMIT from commands like COPY.Uh, not sure how to say that but I don't think we would normally mention that.
Okay.
7 мая 2020 г., в 04:35, Bruce Momjian <bruce@momjian.us> написал(а):
On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
5 мая 2020 г., в 08:16, Bruce Momjian <bruce@momjian.us> написал(а):
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything pglz-compressed) decompression should be significantly faster in v13.
https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06OK, I read the thread mentioned in the commit message and I now see the
value of this change. Attached is the release note diff. Let me know
if it needs improvement.
There is one minor typo retrievel -> retrieval.
Thanks!
Best regards, Andrey Borodin.
Hello Bruce,
* "DOCUMENT THE DEFAULT GENERATION METHOD"
=> The default is still to generate data client-side.My point is that the docs are not clear about this.
Indeed.
Can you fix it?
Sure. Attached patch adds an explicit sentence about it, as it was only
hinted about in the default initialization command string, and removes a
spurious empty paragraph found nearby.Thanks, patch applied.
Ok.
You might remove the "DOCUMENT THE DEFAULT…" in the release note.
I'm wondering about the commit comment: "Reported-by: Fabien COELHO",
actually you reported it, not me!
After looking again at the release notes, I do really think that
significant documentation changes do not belong to the "Source code"
section but should be in separate "Documentation" section, and that more
items should be listed there, because they represent a lot of not-so-fun
work, especially Tom's restructuration of tables, and possibly others.
About pgbench, ISTM that d37ddb745be07502814635585cbf935363c8a33d is worth
mentionning because it is a user-visible change.
--
Fabien.
On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
Hi Bruce,
On Tue, May 5, 2020 at 12:16 PM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Thanks for this as always.
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org> +2019-08-07 [4e85642d9] Apply constraint exclusion more generally in partitionin +Author: Alvaro Herrera <alvherre@alvh.no-ip.org> +2019-08-13 [815ef2f56] Don't constraint-exclude partitioned tables as much +--> + +<para> +Improve cases where pruning of partitions can happen (Amit Langote, Yuzuko Hosoya, �lvaro Herrera) +</para>The following commit should be included with this item:
commit 489247b0e615592111226297a0564e11616361a5
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Sun Aug 4 11:18:45 2019 -0400Improve pruning of a default partition
Primary author for this commit and the person who raised various
problems that led to these improvements is Yuzuko Hosoya. So I think
her name should go first.
OK, I have moved her name to be first. FYI, this commit was backpatched
back through PG 11, though the commit message doesn't mention that.
commit 8654407148
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Sun Aug 4 11:18:45 2019 -0400
Improve pruning of a default partition
When querying a partitioned table containing a default partition, we
were wrongly deciding to include it in the scan too early in the
process, failing to exclude it in some cases. If we reinterpret the
PruneStepResult.scan_default flag slightly, we can do a better job at
detecting that it can be excluded. The change is that we avoid setting
the flag for that pruning step unless the step absolutely requires the
default partition to be scanned (in contrast with the previous
arrangement, which was to set it unless the step was able to prune it).
So get_matching_partitions() must explicitly check the partition that
each returned bound value corresponds to in order to determine whether
the default one needs to be included, rather than relying on the flag
from the final step result.
Author: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>
Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Discussion: /messages/by-id/00e601d4ca86$932b8bc0$b982a340$@lab.ntt.co.jp
FYI, I don't see backpatched commits when creating the release notes.
+Author: Etsuro Fujita <efujita@postgresql.org> +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases. +Author: Tom Lane <tgl@sss.pgh.pa.us> +2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN +--> + +<para> +Allow partitionwise joins to happen in more cases (Ashutosh Bapat, Etsuro Fujita, Amit Langote) +</para>Maybe it would be better to break this into two items, because while
c8434d64c is significant new functionality that I only contributed a
few review comments towards, 981643dcd is relatively minor surgery of
What text would we use for the new item? I thought FULL JOIN was just
another case that matched the description I had.
partitionwise join code to handle FULL JOINs correctly. Tom's rewrite
of my patch for the latter was pretty significant too, so maybe better
to list his name as well.
OK, I have added Tom's name.
+<!-- +Author: Peter Eisentraut <peter@eisentraut.org> +2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit +--> + +<para> +Allow logical replication to replicate partitioned tables (Amit Langote) +</para> + +</listitem> + +<listitem> +<!-- +Author: Peter Eisentraut <peter@eisentraut.org> +2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication +--> + +<para> +Allow partitioned tables to be added to replicated publications (Amit Langote) +</para> + +<para> +Partition additions/removals are replicated as well. Previously, partitions had to be replicated individually. HOW IS THIS DIFFERENT FROM THE ITEM ABOVE? +</para>The former is subscription-side new functionality and the latter is
publication-side and the two are somewhat independent.Till now, logical replication could only occur between relkind 'r'
relations. So the only way to keep a given partitioned table in sync
on the two servers was to manually add the leaf partitions (of relkind
'r') to a publication and also manually keep the list of replicated
tables up to date as partitions come and go, that is, by
adding/removing them to/from the publication.17b9e7f9f (the second item) makes it possible for the partitioned
table (relkind 'p') to be added to the publication so that individual
leaf partitions need not be manually kept in the publication.
Replication still flows between the leaf partitions (relkind 'r'
relations) though.f1ac27bfd (the first item) makes is possible to replicate from a
regular table (relkind 'r') into a partitioned table (relkind 'p').
If a given row is replicated into a partitioned table, the
subscription worker will route it to the correct leaf partition of
that partitioned table.
Wow, that is complicated.
+<listitem> +<!-- +Author: Peter Eisentraut <peter@eisentraut.org> +2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors +--> + +<para> +Allow CREATE PUBLICATION to control whether partitioned tables are published as themselves or their ancestors (Amit Langote) +</para> + +<para> +The option is publish_via_partition_root. +</para>And this allows replication to optionally originate from relkind 'p'
relations on the publication server, whereas it could previously only
originate from relkind 'r' relations. Combined with the first item,
users can now replicate between partitioned tables that have a
different set of partitions on the two servers.Maybe it would make sense to combine the three into one item:
<para>
Add support for logical replication of partitioned tables
</para><para>
Logical replication can now occur between partitioned tables, where
previously it would only be allowed between regular tables. A new
publication option <literal>publish_via_partition_root</literal>
controls whether a leaf partition's changes are published as its own
or as that of the ancestor that's actually published.
</para>
I think trying to put this all into one item is too complex, but I did
merge two of the items together, so we have two items now:
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
-->
<para>
Allow partitioned tables to be replicated via publications (Amit Langote)
</para>
<para>
Previously, partitions had to be replicated individually. Now
partitioned tables can be published explicitly causing all partitions
to be automatically published. Addition/removal of partitions from
partitioned tables are automatically added/removed on subscribers.
The CREATE PUBLICATION option publish_via_partition_root controls whether
partitioned tables are published as themselves or their ancestors.
</para>
</listitem>
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
-->
<para>
Allow non-partitioned tables to be logically replicated to subscribers
that receive the rows into partitioned tables (Amit Langote)
</para>
</listitem>
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Thu, May 7, 2020 at 08:48:49AM -0400, Bruce Momjian wrote:
I think trying to put this all into one item is too complex, but I did
merge two of the items together, so we have two items now:
I ended up adjusting the wording again, so please review the commit or
the website:
https://momjian.us/pgsql_docs/release-13.html
Thanks.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Thu, May 7, 2020 at 08:29:55AM +0200, Fabien COELHO wrote:
Hello Bruce,
* "DOCUMENT THE DEFAULT GENERATION METHOD"
=> The default is still to generate data client-side.My point is that the docs are not clear about this.
Indeed.
Can you fix it?
Sure. Attached patch adds an explicit sentence about it, as it was only
hinted about in the default initialization command string, and removes a
spurious empty paragraph found nearby.Thanks, patch applied.
Ok.
You might remove the "DOCUMENT THE DEFAULT…" in the release note.
Oh, yes, of course.
I'm wondering about the commit comment: "Reported-by: Fabien COELHO",
actually you reported it, not me!
Uh, kind of, yeah, but via email, you did. ;-)
After looking again at the release notes, I do really think that significant
documentation changes do not belong to the "Source code" section but should
be in separate "Documentation" section, and that more items should be listed
there, because they represent a lot of not-so-fun work, especially Tom's
restructuration of tables, and possibly others.
Uh, can someone else give an opinion on this? I am not sure how hard or
un-fun an item is should be used as criteria.
About pgbench, ISTM that d37ddb745be07502814635585cbf935363c8a33d is worth
mentionning because it is a user-visible change.
Uh, that is not usually something I mention because, like error message
changes, it is nice, but few people need to know about it before they
see it.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Wed, May 6, 2020 at 07:31:14PM -0500, Justin Pryzby wrote:
On Wed, May 06, 2020 at 07:35:34PM -0400, Bruce Momjian wrote:
On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything pglz-compressed) decompression should be significantly faster in v13.
https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06OK, I read the thread mentioned in the commit message and I now see the
value of this change. Attached is the release note diff. Let me know
if it needs improvement.Sorry I didn't see it earlier, but:
-Improve retrieving of only the leading bytes of TOAST values (Binguo Bao) +Improve speed of TOAST decompression and the retrievel of only the leading bytes of TOAST values (Binguo Bao, Andrey Borodin)retrieval
I will include this with my running doc patch if you don't want to make a
separate commit.
Fixed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Thu, May 7, 2020 at 11:25:47AM +0500, Andrey M. Borodin wrote:
7 мая 2020 г., в 04:35, Bruce Momjian <bruce@momjian.us> написал(а):
On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
5 мая 2020 г., в 08:16, Bruce Momjian <bruce@momjian.us> написал(а):
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything pglz-compressed) decompression should be significantly faster in v13.
https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06OK, I read the thread mentioned in the commit message and I now see the
value of this change. Attached is the release note diff. Let me know
if it needs improvement.There is one minor typo retrievel -> retrieval.
Thanks!
Got it, thanks.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Wed, May 6, 2020 at 10:20:57PM -0700, Noah Misch wrote:
On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
Kyotaro Horiguchi authored that one. (I committed it.) The commit message
noted characteristics, some of which may deserve mention in the notes:Fixed.
I don't see that change pushed (but it's not urgent).
I got stuck on Amit's partition items and my head couldn't process any
more, so I went to bed, and just committed it now. I was afraid to have
pending stuff uncommitted, but I am also hesitant to do a commit for
each change.
- Crash recovery was losing tuples written via COPY TO. This fixes the bug.
This was not backpatched?
Right.
Oh. So you are saying we could lose COPY data on a crash, even after a
commit. That seems bad. Can you show me the commit info? I can't find
it.
- Out-of-tree table access methods will require changes.
Uh, I don't think we mention those.
Okay. This point is relatively-important. On the other hand, the table
access methods known to me have maintainers who follow -hackers. They may
learn that way.
That was my thought.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Wed, May 6, 2020 at 04:01:44PM -0400, Chapman Flack wrote:
On 05/05/20 10:31, Bruce Momjian wrote:
On Tue, May 5, 2020 at 09:20:39PM +0800, John Naylor wrote:
... This patch is
about the server encoding, which formerly needed to be utf-8 for
non-ascii characters. (I think the client encoding doesn't matter as
long as ascii bytes are represented.)+<para> +The UTF-8 characters must be available in the server encoding. +</para>Same here, s/UTF-8/Unicode/.
OK, new text is:
Allow Unicode escapes, e.g., E'\u####', in clients that don't use UTF-8
encoding (Tom Lane)The Unicode characters must be available in the server encoding.
I kept the "UTF-8 encoding" since that is the only Unicode encoding we
support.My understanding also was that it matters little to this change what the
/client's/ encoding is.There used to be a limitation of the server's lexer that would reject
Unicode escapes whenever the /server's/ encoding wasn't UTF-8 (even
if the server's encoding contained the characters the escapes represent).
I think that limitation is what was removed.I don't think the client encoding comes into it at all. Sure, you could
just include the characters literally if they are in the client encoding,
but you might still choose to express them as escapes, and if you do they
get passed that way to the server for interpretation.
Ah, very good point. New text is:
Allow Unicode escapes, e.g., E'\u####', in databases that do not
use UTF-8 encoding (Tom Lane)
The Unicode characters must be available in the database encoding.
I had assumed the patch applied to all of the forms U&'\####',
U&'\+######', E'\u####', and E'\U######' but I don't think I read
the patch to be sure of that.
I am only using E'\u####' as an example.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Bruce Momjian <bruce@momjian.us> writes:
OK, I have moved her name to be first. FYI, this commit was backpatched
back through PG 11, though the commit message doesn't mention that.
If it was back-patched, it should not be appearing in the v13 release
notes at all, surely?
regards, tom lane
Bruce Momjian <bruce@momjian.us> writes:
On Thu, May 7, 2020 at 08:29:55AM +0200, Fabien COELHO wrote:
After looking again at the release notes, I do really think that significant
documentation changes do not belong to the "Source code" section but should
be in separate "Documentation" section, and that more items should be listed
there, because they represent a lot of not-so-fun work, especially Tom's
restructuration of tables, and possibly others.
Uh, can someone else give an opinion on this? I am not sure how hard or
un-fun an item is should be used as criteria.
Historically we don't document documentation changes at all, do we?
It seems (a) pointless and (b) circular.
regards, tom lane
On Thu, May 7, 2020 at 09:49:49AM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
OK, I have moved her name to be first. FYI, this commit was backpatched
back through PG 11, though the commit message doesn't mention that.If it was back-patched, it should not be appearing in the v13 release
notes at all, surely?
Well, her name was there already for a later commit that was not
backpatched, so I just moved her name earlier. The fact that her name
was moved earlier because of something that was backpatched is
inconsistent, but I don't know enough about the work that went into the
item to comment on that. I will need someone to tell me, of the commits
that only appear in PG 13, what should be the name order.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Thu, May 7, 2020 at 11:12 PM Bruce Momjian <bruce@momjian.us> wrote:
On Thu, May 7, 2020 at 09:49:49AM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
OK, I have moved her name to be first. FYI, this commit was backpatched
back through PG 11, though the commit message doesn't mention that.If it was back-patched, it should not be appearing in the v13 release
notes at all, surely?Well, her name was there already for a later commit that was not
backpatched, so I just moved her name earlier. The fact that her name
was moved earlier because of something that was backpatched is
inconsistent, but I don't know enough about the work that went into the
item to comment on that. I will need someone to tell me, of the commits
that only appear in PG 13, what should be the name order.
Sorry, I misremembered that the patch to make default partition
pruning more aggressive was not backpatched, because I thought at the
time that the patch had turned somewhat complex, but indeed it was
backpatched; in 11.5 release notes:
Prune a partitioned table's default partition (that is, avoid
uselessly scanning it) in more cases (Yuzuko Hosoya)
Sorry for the noise.
I think it's okay for her name to appear first even considering the
commits that only appear in PG 13, because my role was mainly
reviewing the work and perhaps posting an updated version of her
patch.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
On Thu, May 7, 2020 at 9:48 PM Bruce Momjian <bruce@momjian.us> wrote:
On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
+Author: Etsuro Fujita <efujita@postgresql.org> +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases. +Author: Tom Lane <tgl@sss.pgh.pa.us> +2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN +--> + +<para> +Allow partitionwise joins to happen in more cases (Ashutosh Bapat, Etsuro Fujita, Amit Langote) +</para>Maybe it would be better to break this into two items, because while
c8434d64c is significant new functionality that I only contributed a
few review comments towards, 981643dcd is relatively minor surgery ofWhat text would we use for the new item? I thought FULL JOIN was just
another case that matched the description I had.
c8434d64c implements a new feature whereby, to use partitionwise join,
partition bounds of the tables being joined no longer have to match
exactly. I think it might be better to mention this explicitly
because it enables partitionwise joins to be used in more partitioning
setups.
981643dcd fixes things so that 3-way and higher FULL JOINs can now be
performed partitionwise. I am okay with even omitting this if it
doesn't sound big enough to be its own item.
I think trying to put this all into one item is too complex, but I did
merge two of the items together, so we have two items now:<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
--><para>
Allow partitioned tables to be replicated via publications (Amit Langote)
</para><para>
Previously, partitions had to be replicated individually. Now
partitioned tables can be published explicitly causing all partitions
to be automatically published. Addition/removal of partitions from
partitioned tables are automatically added/removed on subscribers.
The CREATE PUBLICATION option publish_via_partition_root controls whether
partitioned tables are published as themselves or their ancestors.
</para>
Thanks. Sounds good except I think the last sentence should read:
...controls whether partition changes are published as their own or as
their ancestor's.
</listitem>
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
--><para>
Allow non-partitioned tables to be logically replicated to subscribers
that receive the rows into partitioned tables (Amit Langote)
</para>
Hmm, why it make it sound like this works only if the source table is
non-partitioned? The source table can be anything, a regular
non-partitioned table, or a partitioned one.
How about:
Allow logical replication into partitioned tables on subscribers
Previously, it was allowed only into regular [ non-partitioned ] tables.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
On Thu, May 7, 2020 at 11:30:40PM +0900, Amit Langote wrote:
On Thu, May 7, 2020 at 11:12 PM Bruce Momjian <bruce@momjian.us> wrote:
Well, her name was there already for a later commit that was not
backpatched, so I just moved her name earlier. The fact that her name
was moved earlier because of something that was backpatched is
inconsistent, but I don't know enough about the work that went into the
item to comment on that. I will need someone to tell me, of the commits
that only appear in PG 13, what should be the name order.Sorry, I misremembered that the patch to make default partition
pruning more aggressive was not backpatched, because I thought at the
time that the patch had turned somewhat complex, but indeed it was
backpatched; in 11.5 release notes:Prune a partitioned table's default partition (that is, avoid
uselessly scanning it) in more cases (Yuzuko Hosoya)Sorry for the noise.
I think it's okay for her name to appear first even considering the
commits that only appear in PG 13, because my role was mainly
reviewing the work and perhaps posting an updated version of her
patch.
OK, confirmed, thanks.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Fri, May 8, 2020 at 12:32:16AM +0900, Amit Langote wrote:
On Thu, May 7, 2020 at 9:48 PM Bruce Momjian <bruce@momjian.us> wrote:
On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
+Author: Etsuro Fujita <efujita@postgresql.org> +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases. +Author: Tom Lane <tgl@sss.pgh.pa.us> +2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN +--> + +<para> +Allow partitionwise joins to happen in more cases (Ashutosh Bapat, Etsuro Fujita, Amit Langote) +</para>Maybe it would be better to break this into two items, because while
c8434d64c is significant new functionality that I only contributed a
few review comments towards, 981643dcd is relatively minor surgery ofWhat text would we use for the new item? I thought FULL JOIN was just
another case that matched the description I had.c8434d64c implements a new feature whereby, to use partitionwise join,
partition bounds of the tables being joined no longer have to match
exactly. I think it might be better to mention this explicitly
because it enables partitionwise joins to be used in more partitioning
setups.
Well, the text says:
Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
Etsuro Fujita, Amit Langote, Tom Lane)
Isn't that what you just said? I just added this paragraph:
For example, partitionwise joins can now happen between partitioned
tables where the ancestors do not exactly match.
Does that help?
981643dcd fixes things so that 3-way and higher FULL JOINs can now be
performed partitionwise. I am okay with even omitting this if it
doesn't sound big enough to be its own item.I think trying to put this all into one item is too complex, but I did
merge two of the items together, so we have two items now:<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
--><para>
Allow partitioned tables to be replicated via publications (Amit Langote)
</para><para>
Previously, partitions had to be replicated individually. Now
partitioned tables can be published explicitly causing all partitions
to be automatically published. Addition/removal of partitions from
partitioned tables are automatically added/removed on subscribers.
The CREATE PUBLICATION option publish_via_partition_root controls whether
partitioned tables are published as themselves or their ancestors.
</para>Thanks. Sounds good except I think the last sentence should read:
...controls whether partition changes are published as their own or as
their ancestor's.
OK, done.
</listitem>
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
--><para>
Allow non-partitioned tables to be logically replicated to subscribers
that receive the rows into partitioned tables (Amit Langote)
</para>Hmm, why it make it sound like this works only if the source table is
non-partitioned? The source table can be anything, a regular
non-partitioned table, or a partitioned one.
Well, we already covered the publish partitioned case in the above item.
How about:
Allow logical replication into partitioned tables on subscribers
Previously, it was allowed only into regular [ non-partitioned ] tables.
OK, I used this wording:
Allow logical replication into partitioned tables on subscribers (Amit
Langote)
Previously, subscribers could only receive rows into non-partitioned
tables.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Thu, May 7, 2020 at 2:46 AM Bruce Momjian <bruce@momjian.us> wrote:
<para>
Allow CREATE INDEX to specify the GiST signature length and maximum number of integer ranges (Nikita Glukhov)
</para>
Should we specify which particular opclasses are affected? Or at
least mention it affects core and particular contribs?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 05/07/20 09:46, Bruce Momjian wrote:
Ah, very good point. New text is:
Allow Unicode escapes, e.g., E'\u####', in databases that do not
use UTF-8 encoding (Tom Lane)The Unicode characters must be available in the database encoding.
...I am only using E'\u####' as an example.
Hmm, how about:
Allow Unicode escapes, e.g., E'\u####' or U&'\####', to represent
any character available in the database encoding, even when that
encoding is not UTF-8.
which I suggest as I recall more clearly that the former condition
was not that such escapes were always rejected in other encodings; it was
that they were rejected if they represented characters outside of ASCII.
(Yossarian let out a respectful whistle.)
My inclination is to give at least one example each of the E and U&
form, if only so the casual reader of the notes may think "say! I hadn't
heard of that other form!" and be inspired to find out about it. But
perhaps it seems too much.
Regards,
-Chap
Hi Bruce,
On Mon, May 4, 2020 at 8:16 PM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:
I see that you have an entry for the deduplication feature:
"More efficiently store duplicates in btree indexes (Anastasia
Lubennikova, Peter Geoghegan)"
I would like to provide some input on this. Fortunately it's much
easier to explain than the B-Tree work that went into Postgres 12. I
think that you should point out that deduplication works by storing
the duplicates in the obvious way: Only storing the key once per
distinct value (or once per distinct combination of values in the case
of multi-column indexes), followed by an array of TIDs (i.e. a posting
list). Each TID points to a separate row in the table.
It won't be uncommon for this to make indexes as much as 3x smaller
(it depends on a number of different factors that you can probably
guess). I wrote a summary of how it works for power users in the
B-Tree documentation chapter, which you might want to link to in the
release notes:
https://www.postgresql.org/docs/devel/btree-implementation.html#BTREE-DEDUPLICATION
Users that pg_upgrade will have to REINDEX to actually use the
feature, regardless of which version they've upgraded from. There are
also some limited caveats about the data types that can use
deduplication, and stuff like that -- see the documentation section I
linked to.
Finally, you might want to note that the feature is enabled by
default, and can be disabled by setting the "deduplicate_items" index
storage option to "off". (We have yet to make a final decision on
whether the feature should be enabled before the first stable release
of Postgres 13, though -- I have an open item for that.)
--
Peter Geoghegan
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Thanks Bruce for compiling the release notes. Here are some comments
from me, after looking at the state of the notes as of f2ff203.
Should e2e02191 be added to the notes? This commit means that we
actually dropped support for Windows 2000 (finally) at run-time.
At the same time I see no mention of 79dfa8af, which added better
error handling when backends the SSL context with incorrect bounds.
What about fc8cb94, which basically means that vacuumlo and oid2name
are able to now support coloring output for their logging?
<para>
Document color support (Peter Eisentraut)
</para>
[...]
<para>
THIS WAS NOT DOCUMENTED BEFORE?
</para>
Not sure that there is a point to add that to the release notes.
--
Michael
On Fri, May 8, 2020 at 2:06 AM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, May 8, 2020 at 12:32:16AM +0900, Amit Langote wrote:
c8434d64c implements a new feature whereby, to use partitionwise join,
partition bounds of the tables being joined no longer have to match
exactly. I think it might be better to mention this explicitly
because it enables partitionwise joins to be used in more partitioning
setups.Well, the text says:
Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
Etsuro Fujita, Amit Langote, Tom Lane)Isn't that what you just said? I just added this paragraph:
For example, partitionwise joins can now happen between partitioned
tables where the ancestors do not exactly match.Does that help?
Yes, although "ancestors do not exactly match" doesn't make clear what
about partitioned tables doesn't match. "partition bounds do not
exactly match" would.
<para>
Previously, partitions had to be replicated individually. Now
partitioned tables can be published explicitly causing all partitions
to be automatically published. Addition/removal of partitions from
partitioned tables are automatically added/removed on subscribers.
The CREATE PUBLICATION option publish_via_partition_root controls whether
partitioned tables are published as themselves or their ancestors.
</para>Thanks. Sounds good except I think the last sentence should read:
...controls whether partition changes are published as their own or as
their ancestor's.OK, done.
Hmm, I see that you only took "as their own".
- ...controls whether partitioned tables are published as themselves
or their ancestors.
+ ...controls whether partitioned tables are published as their own or
their ancestors.and that makes the new sentence sound less clear. I mainly wanted
"partitioned table" replaced by "partition", because only then the
phrase "as their own or their ancestor's" would make sense.
I know our partitioning terminology can be very confusing with many
terms including at least "partitioned table", "partition", "ancestor",
"leaf partition", "parent", "child", etc. that I see used.
</listitem>
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
--><para>
Allow non-partitioned tables to be logically replicated to subscribers
that receive the rows into partitioned tables (Amit Langote)
</para>Hmm, why it make it sound like this works only if the source table is
non-partitioned? The source table can be anything, a regular
non-partitioned table, or a partitioned one.Well, we already covered the publish partitioned case in the above item.
How about:
Allow logical replication into partitioned tables on subscribers
Previously, it was allowed only into regular [ non-partitioned ] tables.
OK, I used this wording:
Allow logical replication into partitioned tables on subscribers (Amit
Langote)Previously, subscribers could only receive rows into non-partitioned
tables.
This is fine, thanks.
I have attached a patch with my suggestions above.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
Attachments:
partition-item-wording.patchapplication/octet-stream; name=partition-item-wording.patchDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 239586c..ec2eee4 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -273,7 +273,7 @@ Allow partitionwise joins to happen in more cases (Ashutosh Bapat, Etsuro Fujita
<para>
For example, partitionwise joins can now happen between partitioned
-tables where the ancestors do not exactly match.
+tables even where their partition bounds do not exactly match.
</para>
</listitem>
@@ -307,7 +307,7 @@ Allow partitioned tables to be logically replicated via publications (Amit Lango
<para>
Previously, partitions had to be replicated individually. Now partitioned tables can be published explicitly causing all partitions to be automatically published. Addition/removal of partitions from
-partitioned tables are automatically added/removed from publications. The CREATE PUBLICATION option publish_via_partition_root controls whether partitioned tables are published as their own or their ancestors.
+partitioned tables are automatically added/removed from publications. The CREATE PUBLICATION option publish_via_partition_root controls whether changes to partitions are published as their own or their ancestor's.
</para>
</listitem>
On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
On Wed, May 6, 2020 at 10:20:57PM -0700, Noah Misch wrote:
On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
Kyotaro Horiguchi authored that one. (I committed it.) The commit message
noted characteristics, some of which may deserve mention in the notes:Fixed.
I don't see that change pushed (but it's not urgent).
I got stuck on Amit's partition items and my head couldn't process any
more, so I went to bed, and just committed it now. I was afraid to have
pending stuff uncommitted, but I am also hesitant to do a commit for
each change.
Got it, +1 for batching such changes.
- Crash recovery was losing tuples written via COPY TO. This fixes the bug.
This was not backpatched?
Right.
Oh. So you are saying we could lose COPY data on a crash, even after a
commit. That seems bad. Can you show me the commit info? I can't find
it.
commit c6b9204
Author: Noah Misch <noah@leadboat.com>
AuthorDate: Sat Apr 4 12:25:34 2020 -0700
Commit: Noah Misch <noah@leadboat.com>
CommitDate: Sat Apr 4 12:25:34 2020 -0700
Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.
To maintain data durability, just before commit, we choose between an
fsync of the relfilenode and copying its contents to WAL. A new GUC,
wal_skip_threshold, guides that choice. If this change slows a workload
that creates small, permanent relfilenodes under wal_level=minimal, try
adjusting wal_skip_threshold. Users setting a timeout on COMMIT may
need to adjust that timeout, and log_min_duration_statement analysis
will reflect time consumption moving to COMMIT from commands like COPY.
Internally, this requires a reliable determination of whether
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's
current relfilenode. Introduce rd_firstRelfilenodeSubid. Amend the
specification of rd_createSubid such that the field is zero when a new
rel has an old rd_node. Make relcache.c retain entries for certain
dropped relations until end of transaction.
Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN.
Future servers accept older WAL, so this bump is discretionary.
Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert
Haas. Heikki Linnakangas and Michael Paquier implemented earlier
designs that materially clarified the problem. Reviewed, in earlier
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,
Fujii Masao, and Simon Riggs. Reported by Martijn van Oosterhout.
Discussion: /messages/by-id/20150702220524.GA9392@svana.org
Hello Tom,
Uh, can someone else give an opinion on this? I am not sure how hard or
un-fun an item is should be used as criteria.
Historically we don't document documentation changes at all, do we?
ISTM that the "we did not do it previously" is as weak an argument as
un-fun-ness:-)
It seems (a) pointless
I disagree, on the very principle of free software values as a social
movement.
Documentation improvements should be encouraged, and recognizing these in
the release notes contributes to do that for what is a lot of unpaid work
given freely by many people. I do not see this as "pointless", on the
contrary, having something "free" in a mostly mercantile world is odd
enough to deserve some praise.
How many hours have you spent on the function operator table improvements?
If someone else had contributed that and only that to a release, would it
not justify two lines of implicit thanks somewhere down in the release
notes?
Moreover adding a documentation section costs next to nothing, so what is
the actual point of not doing it? Also, having some documentation
improvements listed under "source code" does not make sense: writing good,
precise and structured English is not "source code".
and (b) circular.
Meh. The whole documentation is "circular" by construction, with
references from one section to the next and back, indexes, glossary,
acronyms, tutorials, whatever.
--
Fabien.
On 2020-05-05 22:29, Bruce Momjian wrote:
a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
2fc2a88e67 Remove obsolete information schema tablesUh, that didn't seem significant.
Maybe have one item "modernize information_schema", and then describe
all the changes together in a single item.Uh, so I am unclear when we are adding items to information_schema
because we now support them, and when they are new features of
information_schema.
The addition was because it's a new SQL standard part that was published
in the meantime.
The removals were because they no longer exist in the current standard
version and keeping them otherwise didn't make sense.
Neither of these need to be mentioned in the release notes IMO.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, May 5, 2020 at 8:46 AM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:
Thanks for the work. I was today going through the release notes and
was wondering whether we should consider adding information about some
other work done for PG13.
1. We have allowed an (auto)vacuum to display additional information
about heap or index in case of an error in commit b61d161c14 [1]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b61d161c146328ae6ba9ed937862d66e5c8b035a.
Now, in general, it might not be worth saying much about error
information but I think this one could help users in case they have
some corruption. For example, if one of the indexes on a relation has
some corrupted data (due to bad hardware or some bug), it will let the
user know the index information, and the user can take appropriate
action like either Reindex or maybe drop and recreate the index to
overcome the problem.
2. In the "Source Code" section, we can add information about
infrastructure enhancement for parallelism. Basically, "Allow
relation extension and page lock to conflict among parallel-group
members" [2]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=85f6b49c2c53fb1e08d918ec9305faac13cf7ad6[3]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3ba59ccc896e8877e2fbfb8d4f148904cad5f9b0. This will allow improving the parallelism further in
many cases like (a) we can allow multiple workers to operate on a heap
and index in a parallel vacuum, (b) we can allow parallel Inserts,
etc.
[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b61d161c146328ae6ba9ed937862d66e5c8b035a
[2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=85f6b49c2c53fb1e08d918ec9305faac13cf7ad6
[3]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3ba59ccc896e8877e2fbfb8d4f148904cad5f9b0
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Fri, May 8, 2020 at 12:07 PM Amit Langote <amitlangote09@gmail.com> wrote:
On Fri, May 8, 2020 at 2:06 AM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, May 8, 2020 at 12:32:16AM +0900, Amit Langote wrote:
c8434d64c implements a new feature whereby, to use partitionwise join,
partition bounds of the tables being joined no longer have to match
exactly. I think it might be better to mention this explicitly
because it enables partitionwise joins to be used in more partitioning
setups.Well, the text says:
Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
Etsuro Fujita, Amit Langote, Tom Lane)Isn't that what you just said? I just added this paragraph:
For example, partitionwise joins can now happen between partitioned
tables where the ancestors do not exactly match.Does that help?
Yes, although "ancestors do not exactly match" doesn't make clear what
about partitioned tables doesn't match. "partition bounds do not
exactly match" would.
+1 for that change.
Thank you for taking the time to this!
Best regards,
Etsuro Fujita
In ltree, when using adjacent asterisks with braces, e.g. "*{2}.*{3}", properly interpret that as "*{5}" (Nikita Glukhov)
I think that should say ".*" not "*", as in:
In ltree, when using adjacent asterisks with braces, e.g. ".*{2}.*{3}", properly interpret that as "*{5}" (Nikita Glukhov)
The existing text clearly came from the commit message, which (based on its
regression tests) I think was the source of the missing dot.
commit 9950c8aadf0edd31baec74a729d47d94af636c06
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat Mar 28 18:31:05 2020 -0400
Fix lquery's behavior for consecutive '*' items.
Something like "*{2}.*{3}" should presumably mean the same as
"*{5}", but it didn't. Improve that.
...
--
Justin
On Sat, May 9, 2020 at 11:16 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, May 5, 2020 at 8:46 AM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:Thanks for the work. I was today going through the release notes and
was wondering whether we should consider adding information about some
other work done for PG13.
1. We have allowed an (auto)vacuum to display additional information
about heap or index in case of an error in commit b61d161c14 [1].
Now, in general, it might not be worth saying much about error
information but I think this one could help users in case they have
some corruption. For example, if one of the indexes on a relation has
some corrupted data (due to bad hardware or some bug), it will let the
user know the index information, and the user can take appropriate
action like either Reindex or maybe drop and recreate the index to
overcome the problem.
2. In the "Source Code" section, we can add information about
infrastructure enhancement for parallelism. Basically, "Allow
relation extension and page lock to conflict among parallel-group
members" [2][3]. This will allow improving the parallelism further in
many cases like (a) we can allow multiple workers to operate on a heap
and index in a parallel vacuum, (b) we can allow parallel Inserts,
etc.
One more observation:
Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
Praliaskouski)
This new behavior allows pages to be set as all-visible, which then
allows index-only scans, ...
The above sentence sounds to mean that this feature allows index-only
scans in more number of cases after this feature. Is that what you
intend to say? If so, is that correct? Because I think this will
allow index-only scans to skip "Heap Fetches" in more cases.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Hi Bruce,
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Thanks for working on this! :-D
Could you add "Vinayak Pokale" as a co-author of the following feature since
I sometimes read his old patch to create a patch [1]/messages/by-id/20190813140127.GA4933@alvherre.pgsql ?
=======================
E.1.3.1.6. System Views
- Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada)
+ Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada, Vinayak Pokale)
=======================
[1]: /messages/by-id/20190813140127.GA4933@alvherre.pgsql
/messages/by-id/20190813140127.GA4933@alvherre.pgsql
Thanks,
Tatsuro Yamada
On Thu, May 7, 2020 at 08:12:30PM +0300, Alexander Korotkov wrote:
On Thu, May 7, 2020 at 2:46 AM Bruce Momjian <bruce@momjian.us> wrote:
<para>
Allow CREATE INDEX to specify the GiST signature length and maximum number of integer ranges (Nikita Glukhov)
</para>Should we specify which particular opclasses are affected? Or at
least mention it affects core and particular contribs?
Sorry for the delay in replying. Yes, I agree we should list all of
those operator class cases where we now take arguments. I looked at the
patch but got confused and missed the doc changes that clearly need to
be in the release notes. I see these operator classes now taking
parameters, as you helpfully listed in your commit message:
tsvector_ops
gist_ltree_ops
gist__ltree_ops
gist_trgm_ops
gist_hstore_ops
gist__int_ops
gist__intbig_ops
I assume the double-underscore is because the first underscore is to
separate words, and the second one is for the array designation, right?
So my big question is whether people will understand when they are using
these operator classes, since many of them are defaults. Can you use an
operator class parameter when you are just using the default operator
class and not specifying its name? What I thinking that just saying
the operator class take arguments might not be helpful. I think I see
enough detail in the documentation to write release note items for
these, but I will have to point out they need to specify the operator
class, even if it is the default, right?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 4:20 PM Bruce Momjian <bruce@momjian.us> wrote:
Sorry for the delay in replying. Yes, I agree we should list all of
those operator class cases where we now take arguments. I looked at the
patch but got confused and missed the doc changes that clearly need to
be in the release notes. I see these operator classes now taking
parameters, as you helpfully listed in your commit message:tsvector_ops
gist_ltree_ops
gist__ltree_ops
gist_trgm_ops
gist_hstore_ops
gist__int_ops
gist__intbig_opsI assume the double-underscore is because the first underscore is to
separate words, and the second one is for the array designation, right?
Yes, this is true.
So my big question is whether people will understand when they are using
these operator classes, since many of them are defaults. Can you use an
operator class parameter when you are just using the default operator
class and not specifying its name?
Actually no. Initial version of patch allowed to explicitly specify
DEFAULT keyword instead of opclass name. But I didn't like idea to
allow keyword instead of name there.
I've tried to implement syntax allowing specifying parameters without
both new keyword and opclass name, but that causes a lot of grammar
problems.
Finally, I've decided to provide parameters functionality only when
specifying opclass name. My motivation is that opclass parameters is
functionality for advanced users, who are deeply concerned into what
opclass do. For this category of users it's natural to know the
opclass name.
What I thinking that just saying
the operator class take arguments might not be helpful. I think I see
enough detail in the documentation to write release note items for
these, but I will have to point out they need to specify the operator
class, even if it is the default, right?
My point was that we should specify where to look to find new
functionality. We can don't write opclass names, because those names
might be confusing for users who are not aware of them. We may
briefly say that new parameters are introduced for GiST for tsvector,
contrib/intarray, contrib/pg_trgm, contrib/ltree, contrib/hstore.
What do you think?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hello
+<!-- +Author: Alexander Korotkov <akorotkov@postgresql.org> +2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql +--> + +<para> +Add psql commands to report operator classes and operator families (Sergey Cherkashin, Nikita Glukhov, Alexander Korotkov) +</para>
I think this item should list the commands in question:
\dA, \dAc, \dAf, \dAo, \dAp
(All the other psql entries in the relnotes do that).
Thanks
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-May-11, Alvaro Herrera wrote:
Hello
+<!-- +Author: Alexander Korotkov <akorotkov@postgresql.org> +2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql +--> + +<para> +Add psql commands to report operator classes and operator families (Sergey Cherkashin, Nikita Glukhov, Alexander Korotkov) +</para>I think this item should list the commands in question:
\dA, \dAc, \dAf, \dAo, \dAp
(All the other psql entries in the relnotes do that).
Sorry, it's the last four only -- \dA is an older command.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, May 11, 2020 at 08:41:00PM +0300, Alexander Korotkov wrote:
On Mon, May 11, 2020 at 4:20 PM Bruce Momjian <bruce@momjian.us> wrote:
Sorry for the delay in replying. Yes, I agree we should list all of
those operator class cases where we now take arguments. I looked at the
patch but got confused and missed the doc changes that clearly need to
be in the release notes. I see these operator classes now taking
parameters, as you helpfully listed in your commit message:tsvector_ops
gist_ltree_ops
gist__ltree_ops
gist_trgm_ops
gist_hstore_ops
gist__int_ops
gist__intbig_opsI assume the double-underscore is because the first underscore is to
separate words, and the second one is for the array designation, right?Yes, this is true.
OK.
So my big question is whether people will understand when they are using
these operator classes, since many of them are defaults. Can you use an
operator class parameter when you are just using the default operator
class and not specifying its name?Actually no. Initial version of patch allowed to explicitly specify
DEFAULT keyword instead of opclass name. But I didn't like idea to
allow keyword instead of name there.I've tried to implement syntax allowing specifying parameters without
both new keyword and opclass name, but that causes a lot of grammar
problems.Finally, I've decided to provide parameters functionality only when
specifying opclass name. My motivation is that opclass parameters is
functionality for advanced users, who are deeply concerned into what
opclass do. For this category of users it's natural to know the
opclass name.
Yes, that is good analysis, and your final decision was probably
correct. I now see that the complexity is not a big problem.
What I thinking that just saying
the operator class take arguments might not be helpful. I think I see
enough detail in the documentation to write release note items for
these, but I will have to point out they need to specify the operator
class, even if it is the default, right?My point was that we should specify where to look to find new
functionality. We can don't write opclass names, because those names
might be confusing for users who are not aware of them. We may
briefly say that new parameters are introduced for GiST for tsvector,
contrib/intarray, contrib/pg_trgm, contrib/ltree, contrib/hstore.
What do you think?
OK, I have applied the attached patch, which I now think is the right
level of detail, given your information above. Thanks.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Attachments:
gist.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
new file mode 100644
index 239586c..c0840c2
*** a/doc/src/sgml/release-13.sgml
--- b/doc/src/sgml/release-13.sgml
*************** Author: Alexander Korotkov <akorotkov@po
*** 409,414 ****
--- 409,418 ----
Allow CREATE INDEX to specify the GiST signature length and maximum number of integer ranges (Nikita Glukhov)
</para>
+ <para>
+ Indexes created on four and eight-byte integer array, tsvector, trigram,
+ ltree, and hstore columns can now control these GiST index parameters,
+ rather than using the defaults.
</listitem>
<listitem>
On Thu, May 7, 2020 at 02:08:58PM -0400, Chapman Flack wrote:
On 05/07/20 09:46, Bruce Momjian wrote:
Ah, very good point. New text is:
Allow Unicode escapes, e.g., E'\u####', in databases that do not
use UTF-8 encoding (Tom Lane)The Unicode characters must be available in the database encoding.
...I am only using E'\u####' as an example.
Hmm, how about:
Allow Unicode escapes, e.g., E'\u####' or U&'\####', to represent
any character available in the database encoding, even when that
encoding is not UTF-8.which I suggest as I recall more clearly that the former condition
was not that such escapes were always rejected in other encodings; it was
that they were rejected if they represented characters outside of ASCII.
(Yossarian let out a respectful whistle.)
I like your wording, but the "that encoding" wasn't clear enough for me,
so I reworded it to:
Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
character available in the database encoding, even when the database
encoding is not UTF-8 (Tom Lane)
My inclination is to give at least one example each of the E and U&
form, if only so the casual reader of the notes may think "say! I hadn't
heard of that other form!" and be inspired to find out about it. But
perhaps it seems too much.
Sure, works for me.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Thu, May 7, 2020 at 11:54:12AM -0700, Peter Geoghegan wrote:
Hi Bruce,
On Mon, May 4, 2020 at 8:16 PM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:I see that you have an entry for the deduplication feature:
"More efficiently store duplicates in btree indexes (Anastasia
Lubennikova, Peter Geoghegan)"I would like to provide some input on this. Fortunately it's much
easier to explain than the B-Tree work that went into Postgres 12. I
-----------------
Well, that's good! :-)
think that you should point out that deduplication works by storing
the duplicates in the obvious way: Only storing the key once per
distinct value (or once per distinct combination of values in the case
of multi-column indexes), followed by an array of TIDs (i.e. a posting
list). Each TID points to a separate row in the table.
These are not details that should be in the release notes since the
internal representation is not important for its use.
It won't be uncommon for this to make indexes as much as 3x smaller
(it depends on a number of different factors that you can probably
guess). I wrote a summary of how it works for power users in the
B-Tree documentation chapter, which you might want to link to in the
release notes:https://www.postgresql.org/docs/devel/btree-implementation.html#BTREE-DEDUPLICATION
Users that pg_upgrade will have to REINDEX to actually use the
feature, regardless of which version they've upgraded from. There are
also some limited caveats about the data types that can use
deduplication, and stuff like that -- see the documentation section I
linked to.
I have added text to this about pg_upgrade:
Users upgrading with pg_upgrade will need to use REINDEX to make
use of this feature.
Finally, you might want to note that the feature is enabled by
default, and can be disabled by setting the "deduplicate_items" index
storage option to "off". (We have yet to make a final decision on
whether the feature should be enabled before the first stable release
of Postgres 13, though -- I have an open item for that.)
Well, again, I don't think the average user needs to know this can be
disabled. They can look at the docs of this feature to see that.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Fri, May 8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Thanks Bruce for compiling the release notes. Here are some comments
from me, after looking at the state of the notes as of f2ff203.Should e2e02191 be added to the notes? This commit means that we
actually dropped support for Windows 2000 (finally) at run-time.
Oh, yes. This is much more important than the removal of support for
non-ELF BSD systems, which I already listed. The new text is:
Remove support for Windows 2000 (Michael Paquier)
At the same time I see no mention of 79dfa8af, which added better
error handling when backends the SSL context with incorrect bounds.
I skipped that commit since people don't normally care about better
error messages until they see the error message, and then they are happy
it is there, unless this is some chronic error message problem we are
fixing.
What about fc8cb94, which basically means that vacuumlo and oid2name
are able to now support coloring output for their logging?
I thought this fell into the previous category about error messages, but
coloring is different. Can we say these utilities now honor the color
environment variables? Are these the only new ones?
<para>
Document color support (Peter Eisentraut)
</para>
[...]
<para>
THIS WAS NOT DOCUMENTED BEFORE?
</para>
Not sure that there is a point to add that to the release notes.
OK, removed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Fri, May 8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
OK, I used this wording:
Allow logical replication into partitioned tables on subscribers (Amit
Langote)Previously, subscribers could only receive rows into non-partitioned
tables.This is fine, thanks.
I have attached a patch with my suggestions above.
OK, I slightly modified the wording of your first change, patch
attached.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Attachments:
partition.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 239586c04b..51ebb9b2ba 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -273,7 +273,7 @@ Allow partitionwise joins to happen in more cases (Ashutosh Bapat, Etsuro Fujita
<para>
For example, partitionwise joins can now happen between partitioned
-tables where the ancestors do not exactly match.
+tables even when their partition bounds do not match exactly.
</para>
</listitem>
@@ -307,7 +307,7 @@ Allow partitioned tables to be logically replicated via publications (Amit Lango
<para>
Previously, partitions had to be replicated individually. Now partitioned tables can be published explicitly causing all partitions to be automatically published. Addition/removal of partitions from
-partitioned tables are automatically added/removed from publications. The CREATE PUBLICATION option publish_via_partition_root controls whether partitioned tables are published as their own or their ancestors.
+partitioned tables are automatically added/removed from publications. The CREATE PUBLICATION option publish_via_partition_root controls whether changes to partitions are published as their own or their ancestor's.
</para>
</listitem>
On Mon, May 11, 2020 at 4:10 PM Bruce Momjian <bruce@momjian.us> wrote:
think that you should point out that deduplication works by storing
the duplicates in the obvious way: Only storing the key once per
distinct value (or once per distinct combination of values in the case
of multi-column indexes), followed by an array of TIDs (i.e. a posting
list). Each TID points to a separate row in the table.These are not details that should be in the release notes since the
internal representation is not important for its use.
I am not concerned about describing the specifics of the on-disk
representation, and I don't feel too strongly about the storage
parameter (leave it out). I only ask that the wording convey the fact
that the deduplication feature is not just a quantitative improvement
-- it's a qualitative behavioral change, that will help data
warehousing in particular. This wasn't the case with the v12 work on
B-Tree duplicates (as I said last year, I thought of the v12 stuff as
fixing a problem more than an enhancement).
With the deduplication feature added to Postgres v13, the B-Tree code
can now gracefully deal with low cardinality data by compressing the
duplicates as needed. This is comparable to bitmap indexes in
proprietary database systems, but without most of their disadvantages
(in particular around heavyweight locking, deadlocks that abort
transactions, etc). It's easy to imagine this making a big difference
with analytics workloads. The v12 work made indexes with lots of
duplicates 15%-30% smaller (compared to v11), but the v13 work can
make them 60% - 80% smaller in many common cases (compared to v12). In
extreme cases indexes might even be ~12x smaller (though that will be
rare).
--
Peter Geoghegan
On Thu, May 7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
- Crash recovery was losing tuples written via COPY TO. This fixes the bug.
This was not backpatched?
Right.
Oh. So you are saying we could lose COPY data on a crash, even after a
commit. That seems bad. Can you show me the commit info? I can't find
it.commit c6b9204
Author: Noah Misch <noah@leadboat.com>
AuthorDate: Sat Apr 4 12:25:34 2020 -0700
Commit: Noah Misch <noah@leadboat.com>
CommitDate: Sat Apr 4 12:25:34 2020 -0700Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.
OK, so how do we want to document this? Do I mention in the text below
the WAL skipping item that this fixes a bug where a mix of simultaneous
COPY and INSERT into a table could lose rows during crash recovery, or
create a new item?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 05:05:29PM -0700, Peter Geoghegan wrote:
On Mon, May 11, 2020 at 4:10 PM Bruce Momjian <bruce@momjian.us> wrote:
think that you should point out that deduplication works by storing
the duplicates in the obvious way: Only storing the key once per
distinct value (or once per distinct combination of values in the case
of multi-column indexes), followed by an array of TIDs (i.e. a posting
list). Each TID points to a separate row in the table.These are not details that should be in the release notes since the
internal representation is not important for its use.I am not concerned about describing the specifics of the on-disk
representation, and I don't feel too strongly about the storage
parameter (leave it out). I only ask that the wording convey the fact
that the deduplication feature is not just a quantitative improvement
-- it's a qualitative behavioral change, that will help data
warehousing in particular. This wasn't the case with the v12 work on
B-Tree duplicates (as I said last year, I thought of the v12 stuff as
fixing a problem more than an enhancement).With the deduplication feature added to Postgres v13, the B-Tree code
can now gracefully deal with low cardinality data by compressing the
duplicates as needed. This is comparable to bitmap indexes in
proprietary database systems, but without most of their disadvantages
(in particular around heavyweight locking, deadlocks that abort
transactions, etc). It's easy to imagine this making a big difference
with analytics workloads. The v12 work made indexes with lots of
duplicates 15%-30% smaller (compared to v11), but the v13 work can
make them 60% - 80% smaller in many common cases (compared to v12). In
extreme cases indexes might even be ~12x smaller (though that will be
rare).
Agreed. How is this?
This allows efficient btree indexing of low cardinality columns.
Users upgrading with pg_upgrade will need to use REINDEX to make use of
this feature.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Fri, May 8, 2020 at 09:14:01AM +0200, Fabien COELHO wrote:
It seems (a) pointless
I disagree, on the very principle of free software values as a social
movement.Documentation improvements should be encouraged, and recognizing these in
the release notes contributes to do that for what is a lot of unpaid work
given freely by many people. I do not see this as "pointless", on the
contrary, having something "free" in a mostly mercantile world is odd enough
to deserve some praise.How many hours have you spent on the function operator table improvements?
If someone else had contributed that and only that to a release, would it
not justify two lines of implicit thanks somewhere down in the release
notes?Moreover adding a documentation section costs next to nothing, so what is
the actual point of not doing it? Also, having some documentation
improvements listed under "source code" does not make sense: writing good,
precise and structured English is not "source code".
We have long discussed how much of the release notes is to reward
behavior, and we have settled on having the names on the items, and the
Acknowledgments section at the bottom. If you want to revisit that
decision, you should start a new thread because doing it for just this
item doesn't make sense.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Sat, May 9, 2020 at 11:16:27AM +0530, Amit Kapila wrote:
On Tue, May 5, 2020 at 8:46 AM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:Thanks for the work. I was today going through the release notes and
was wondering whether we should consider adding information about some
other work done for PG13.
1. We have allowed an (auto)vacuum to display additional information
about heap or index in case of an error in commit b61d161c14 [1].
Now, in general, it might not be worth saying much about error
information but I think this one could help users in case they have
some corruption. For example, if one of the indexes on a relation has
some corrupted data (due to bad hardware or some bug), it will let the
user know the index information, and the user can take appropriate
action like either Reindex or maybe drop and recreate the index to
overcome the problem.
I mentioned my approach to error message changes in a previous email
today:
I skipped that commit since people don't normally care about
better error messages until they see the error message, and then
they are happy it is there, unless this is some chronic error
message problem we are fixing.
2. In the "Source Code" section, we can add information about
infrastructure enhancement for parallelism. Basically, "Allow
relation extension and page lock to conflict among parallel-group
members" [2][3]. This will allow improving the parallelism further in
many cases like (a) we can allow multiple workers to operate on a heap
and index in a parallel vacuum, (b) we can allow parallel Inserts,
etc.
Uh, if there is no user-visible behavior change, this seems too low
level for the release notes.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
One more observation:
Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
Praliaskouski)
This new behavior allows pages to be set as all-visible, which then
allows index-only scans, ...The above sentence sounds to mean that this feature allows index-only
scans in more number of cases after this feature. Is that what you
intend to say? If so, is that correct? Because I think this will
Yes.
allow index-only scans to skip "Heap Fetches" in more cases.
Uh, by definition an index-only scan only scans the index, not the heap,
right? It is true there are fewer heap fetches, but fewer heap features
I thought mean more index-only scans.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Sun, May 10, 2020 at 03:09:47PM -0500, Justin Pryzby wrote:
In ltree, when using adjacent asterisks with braces, e.g. "*{2}.*{3}", properly interpret that as "*{5}" (Nikita Glukhov)
I think that should say ".*" not "*", as in:
In ltree, when using adjacent asterisks with braces, e.g. ".*{2}.*{3}", properly interpret that as "*{5}" (Nikita Glukhov)
The existing text clearly came from the commit message, which (based on its
regression tests) I think was the source of the missing dot.commit 9950c8aadf0edd31baec74a729d47d94af636c06
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat Mar 28 18:31:05 2020 -0400Fix lquery's behavior for consecutive '*' items.
Something like "*{2}.*{3}" should presumably mean the same as
"*{5}", but it didn't. Improve that.
...
OK, fixed to be:
In ltree, when using adjacent asterisks with braces, e.g. ".*{2}.*{3}",
properly interpret that as ".*{5}" (Nikita Glukhov)
I added two dots.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 5:14 PM Bruce Momjian <bruce@momjian.us> wrote:
Agreed. How is this?
This allows efficient btree indexing of low cardinality columns.
Users upgrading with pg_upgrade will need to use REINDEX to make use of
this feature.
I still think that the release notes should say that the key is only
stored once, while TIDs that identify table rows are stored together
as an array. Everything that's helpful (or harmful) about the feature
happens as a consequence of that. This isn't hard to grasp
intuitively, and is totally in line with how things like Oracle bitmap
indexes are presented to ordinary users.
--
Peter Geoghegan
On Mon, May 11, 2020 at 03:19:50PM +0900, Tatsuro Yamada wrote:
Hi Bruce,
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Thanks for working on this! :-D
Could you add "Vinayak Pokale" as a co-author of the following feature since
I sometimes read his old patch to create a patch [1] ?=======================
E.1.3.1.6. System Views- Add system view pg_stat_progress_analyze to report analyze progress (�lvaro Herrera, Tatsuro Yamada)
+ Add system view pg_stat_progress_analyze to report analyze progress (�lvaro Herrera, Tatsuro Yamada, Vinayak Pokale)
=======================
Done.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On 2020-May-11, Bruce Momjian wrote:
We have long discussed how much of the release notes is to reward
behavior, and we have settled on having the names on the items, and the
Acknowledgments section at the bottom.
Yes, we had to touch the source code in order to add documentation; but
so what? Everything touches the source code, but that doesn't mean it
should be listed there. I don't see what's the problem with having a
new subsection in the relnotes entitled "Documentation" where these two
items appears (glossary + new doc table format) are listed. It's not
like it's going to cost us a lot of space or anything.
I don't think there is any circularity argument BTW -- we're not going
to document that we added release notes. And changing the table format
is not entirely pointless, given that we've historically had trouble
with these tables (read: they're totally unusable in PDF).
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Allow function call backtraces of errors to be logged (Peter Eisentraut, �lvaro Herrera)
|Server variable backtrace_functions specifies which C functions should generate backtraces on error.
I think the details in the description are eclipsing the most important thing:
backtraces on Assert(). I would say "Support for showing backtraces on error".
Regarding this one:
|Add system view pg_shmem_allocations to display shared memory usage (Andres Freund, Robert Haas)
|WHAT IS THE ENTRY WITH NO NAME?
There seems to be two special, "unnamed" cases:
src/backend/storage/ipc/shmem.c- /* output shared memory allocated but not counted via the shmem index */
src/backend/storage/ipc/shmem.c: values[0] = CStringGetTextDatum("<anonymous>");
...
src/backend/storage/ipc/shmem.c- /* output as-of-yet unused shared memory */
src/backend/storage/ipc/shmem.c- nulls[0] = true;
That seems to be adequately documented:
https://www.postgresql.org/docs/devel/view-pg-shmem-allocations.html
|NULL for unused memory and <anonymous> for anonymous allocations.
I would remove this part:
"Previously, this could only be set at server start."
--
Justin
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
1. We have allowed an (auto)vacuum to display additional information
about heap or index in case of an error in commit b61d161c14 [1].
Now, in general, it might not be worth saying much about error
information but I think this one could help users in case they have
some corruption. For example, if one of the indexes on a relation has
some corrupted data (due to bad hardware or some bug), it will let the
user know the index information, and the user can take appropriate
action like either Reindex or maybe drop and recreate the index to
overcome the problem.
I'm not opposed to including it, but I think it's still true that the user
doesn't need to know in advance that the error message will be additionally
helpful in the event of corruption. If we were to include more "error" items,
we might also include these:
71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
17a28b03645e27d73bf69a95d7569b61e58f06eb Improve the internal implementation of ereport().
05f18c6b6b6e4b44302ee20a042cedc664532aa2 Added relation name in error messages for constraint checks.
33753ac9d7bc83dd9ccee9d5e678ed78a0725b4e Add object names to partition integrity violations.
One more observation:
Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
Praliaskouski)
This new behavior allows pages to be set as all-visible, which then
allows index-only scans, ...
The above sentence sounds to mean that this feature allows index-only
scans in more number of cases after this feature. Is that what you
intend to say? If so, is that correct? Because I think this will
allow index-only scans to skip "Heap Fetches" in more cases.
I think what you mean is that the autovacuum feature, in addition to
encouraging the *planner* to choose an indexonly scan, will *also* allow (at
execution time) fewer heap fetches for a plan which would have
already/previously used IOS. Right ? So maybe it should say "allows OR
IMPROVES index-only scans" or "allows plans which use IOS to run more
efficiently".
Separate from Amit's comment, I suggest to say:
| This new behavior allows autovacuum to set pages as all-visible, which then
| allows index-only scans, ...
..otherwise it sounds like this feature implemented the concept of
"all-visible".
--
Justin
On Mon, May 11, 2020 at 04:50:50PM -0400, Alvaro Herrera wrote:
Hello
+<!-- +Author: Alexander Korotkov <akorotkov@postgresql.org> +2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql +--> + +<para> +Add psql commands to report operator classes and operator families (Sergey Cherkashin, Nikita Glukhov, Alexander Korotkov) +</para>I think this item should list the commands in question:
\dA, \dAc, \dAf, \dAo, \dAp
(All the other psql entries in the relnotes do that).
Good idea. I added this paragraph:
The new commands are \dAc, \dAf, \dAo, and \dAp.
I didn't see any changes to \dA except regression tests.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 08:34:56PM -0400, Alvaro Herrera wrote:
On 2020-May-11, Bruce Momjian wrote:
We have long discussed how much of the release notes is to reward
behavior, and we have settled on having the names on the items, and the
Acknowledgments section at the bottom.Yes, we had to touch the source code in order to add documentation; but
so what? Everything touches the source code, but that doesn't mean it
should be listed there. I don't see what's the problem with having a
new subsection in the relnotes entitled "Documentation" where these two
items appears (glossary + new doc table format) are listed. It's not
like it's going to cost us a lot of space or anything.I don't think there is any circularity argument BTW -- we're not going
to document that we added release notes. And changing the table format
is not entirely pointless, given that we've historically had trouble
with these tables (read: they're totally unusable in PDF).
Well, are you suggesting a new section because the glossary shouldn't be
listed under source code, or because you want the function reformatting
added? We just need to understand what the purpose is. We already have
the glossary listed, since that is new and user-visible.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 07:41:55PM -0500, Justin Pryzby wrote:
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
One more observation:
Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
Praliaskouski)
This new behavior allows pages to be set as all-visible, which then
allows index-only scans, ...The above sentence sounds to mean that this feature allows index-only
scans in more number of cases after this feature. Is that what you
intend to say? If so, is that correct? Because I think this will
allow index-only scans to skip "Heap Fetches" in more cases.I think what you mean is that the autovacuum feature, in addition to
encouraging the *planner* to choose an indexonly scan, will *also* allow (at
execution time) fewer heap fetches for a plan which would have
already/previously used IOS. Right ? So maybe it should say "allows OR
IMPROVES index-only scans" or "allows plans which use IOS to run more
efficiently".
Yes, I see your point now. New text is:
This new behavior reduces the work necessary when the table
needs to be frozen and allows pages to be set as all-visible.
All-visible pages allow index-only scans to access fewer heap rows.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 05:09:54PM -0400, Alvaro Herrera wrote:
On 2020-May-11, Alvaro Herrera wrote:
Hello
+<!-- +Author: Alexander Korotkov <akorotkov@postgresql.org> +2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql +--> + +<para> +Add psql commands to report operator classes and operator families (Sergey Cherkashin, Nikita Glukhov, Alexander Korotkov) +</para>I think this item should list the commands in question:
\dA, \dAc, \dAf, \dAo, \dAp
(All the other psql entries in the relnotes do that).Sorry, it's the last four only -- \dA is an older command.
OK, confirmed, thanks.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 07:41:01PM -0500, Justin Pryzby wrote:
|Allow function call backtraces of errors to be logged (Peter Eisentraut, �lvaro Herrera)
|Server variable backtrace_functions specifies which C functions should generate backtraces on error.I think the details in the description are eclipsing the most important thing:
backtraces on Assert(). I would say "Support for showing backtraces on error".
Uh, you mean this adds backtraces for errors and asserts? Are
non-developers running assert builds?
Regarding this one:
|Add system view pg_shmem_allocations to display shared memory usage (Andres Freund, Robert Haas)
|WHAT IS THE ENTRY WITH NO NAME?There seems to be two special, "unnamed" cases:
src/backend/storage/ipc/shmem.c- /* output shared memory allocated but not counted via the shmem index */
src/backend/storage/ipc/shmem.c: values[0] = CStringGetTextDatum("<anonymous>");
...
src/backend/storage/ipc/shmem.c- /* output as-of-yet unused shared memory */
src/backend/storage/ipc/shmem.c- nulls[0] = true;That seems to be adequately documented:
https://www.postgresql.org/docs/devel/view-pg-shmem-allocations.html
|NULL for unused memory and <anonymous> for anonymous allocations.
OK, thanks. Comment removed.
I would remove this part:
"Previously, this could only be set at server start."
OK, you rae saying it is already clear, agreed, removed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
On Mon, May 11, 2020 at 5:14 PM Bruce Momjian <bruce@momjian.us> wrote:
Agreed. How is this?
This allows efficient btree indexing of low cardinality columns.
Users upgrading with pg_upgrade will need to use REINDEX to make use of
this feature.I still think that the release notes should say that the key is only
stored once, while TIDs that identify table rows are stored together
as an array. Everything that's helpful (or harmful) about the feature
happens as a consequence of that. This isn't hard to grasp
intuitively, and is totally in line with how things like Oracle bitmap
indexes are presented to ordinary users.
I still don't think these details belong in the release notes.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 09:15:43PM -0400, Bruce Momjian wrote:
On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
On Mon, May 11, 2020 at 5:14 PM Bruce Momjian <bruce@momjian.us> wrote:
Agreed. How is this?
This allows efficient btree indexing of low cardinality columns.
Users upgrading with pg_upgrade will need to use REINDEX to make use of
this feature.I still think that the release notes should say that the key is only
stored once, while TIDs that identify table rows are stored together
as an array. Everything that's helpful (or harmful) about the feature
happens as a consequence of that. This isn't hard to grasp
intuitively, and is totally in line with how things like Oracle bitmap
indexes are presented to ordinary users.I still don't think these details belong in the release notes.
OK, I was able to add some of it cleanly:
This allows efficient btree indexing of low cardinality columns by
storing duplicate keys only once. Users upgrading with pg_upgrade
will need to use REINDEX to make use of this feature.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 12, 2020 at 8:51 AM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, May 8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
I have attached a patch with my suggestions above.
OK, I slightly modified the wording of your first change, patch
attached.
Thanks. I checked that what you committed looks fine.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
On Mon, May 11, 2020 at 6:23 PM Bruce Momjian <bruce@momjian.us> wrote:
OK, I was able to add some of it cleanly:
This allows efficient btree indexing of low cardinality columns by
storing duplicate keys only once. Users upgrading with pg_upgrade
will need to use REINDEX to make use of this feature.
That seems like a reasonable compromise. Thanks!
--
Peter Geoghegan
On Mon, May 11, 2020 at 07:18:56PM -0400, Bruce Momjian wrote:
On Fri, May 8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
Should e2e02191 be added to the notes? This commit means that we
actually dropped support for Windows 2000 (finally) at run-time.Oh, yes. This is much more important than the removal of support for
non-ELF BSD systems, which I already listed. The new text is:Remove support for Windows 2000 (Michael Paquier)
Sounds fine to me.
At the same time I see no mention of 79dfa8af, which added better
error handling when backends the SSL context with incorrect bounds.I skipped that commit since people don't normally care about better
error messages until they see the error message, and then they are happy
it is there, unless this is some chronic error message problem we are
fixing.
Okay.
I thought this fell into the previous category about error messages, but
coloring is different. Can we say these utilities now honor the color
environment variables?
Exactly, I actually became aware of that possibility after plugging
in the common logging APIs to oid2name and vacuumlo as of fc8cb94b so
this was not mentioned in the log message. And anything using
src/common/logging.c can make use of the colorized output with
PG_COLOR[S] set.
Are these the only new ones?
I can recall an extra one in this case: pgbench as of 30a3e77. And I
don't see any new callers of pg_logging_init() in the stuff that
already existed in ~12.
--
Michael
Bruce Momjian <bruce@momjian.us> writes:
I like your wording, but the "that encoding" wasn't clear enough for me,
so I reworded it to:
Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
character available in the database encoding, even when the database
encoding is not UTF-8 (Tom Lane)
How about "to be used for" instead of "to represent"? "Represent" kind
of sounds like we're using these on output, which we aren't.
regards, tom lane
On 2020-May-11, Bruce Momjian wrote:
On Mon, May 11, 2020 at 08:34:56PM -0400, Alvaro Herrera wrote:
Yes, we had to touch the source code in order to add documentation; but
so what? Everything touches the source code, but that doesn't mean it
should be listed there. I don't see what's the problem with having a
new subsection in the relnotes entitled "Documentation" where these two
items appears (glossary + new doc table format) are listed. It's not
like it's going to cost us a lot of space or anything.
Well, are you suggesting a new section because the glossary shouldn't be
listed under source code, or because you want the function reformatting
added? We just need to understand what the purpose is. We already have
the glossary listed, since that is new and user-visible.
IMO the table reformatting change is significant enough to be
noteworthy. I'm suggesting that a new Documentation subsection would
list both that and the glossary, separately from Source Code -- so it'd
be E.1.3.10 and Source Code would be E.1.3.11.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Bruce Momjian <bruce@momjian.us> writes:
Well, are you suggesting a new section because the glossary shouldn't be
listed under source code, or because you want the function reformatting
added? We just need to understand what the purpose is. We already have
the glossary listed, since that is new and user-visible.
The implication of what you say here is that "is it user-visible?"
is a criterion for whether to release-note something. By that logic
we probably *should* relnote the function table layout changes, because
they sure as heck are user-visible. People might or might not notice
addition of a glossary, but I think just about every user consults
the function/operator tables regularly.
I concur with Alvaro's position that if we are listing documentation
changes, pushing them under "Source Code" is not the way to do it.
That subsection has always been understood to be "stuff you don't
care about if you're not a hacker".
So that sort of leads me to the conclusion that "major documentation
changes" might be a reasonable sub-heading for the release notes.
regards, tom lane
On Tue, May 12, 2020 at 10:54:52AM +0900, Michael Paquier wrote:
On Mon, May 11, 2020 at 07:18:56PM -0400, Bruce Momjian wrote:
On Fri, May 8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
Should e2e02191 be added to the notes? This commit means that we
actually dropped support for Windows 2000 (finally) at run-time.Oh, yes. This is much more important than the removal of support for
non-ELF BSD systems, which I already listed. The new text is:Remove support for Windows 2000 (Michael Paquier)
Sounds fine to me.
At the same time I see no mention of 79dfa8af, which added better
error handling when backends the SSL context with incorrect bounds.I skipped that commit since people don't normally care about better
error messages until they see the error message, and then they are happy
it is there, unless this is some chronic error message problem we are
fixing.Okay.
I thought this fell into the previous category about error messages, but
coloring is different. Can we say these utilities now honor the color
environment variables?Exactly, I actually became aware of that possibility after plugging
in the common logging APIs to oid2name and vacuumlo as of fc8cb94b so
this was not mentioned in the log message. And anything using
src/common/logging.c can make use of the colorized output with
PG_COLOR[S] set.Are these the only new ones?
I can recall an extra one in this case: pgbench as of 30a3e77. And I
don't see any new callers of pg_logging_init() in the stuff that
already existed in ~12.
I am not sure we even mentioned this in 12. Should we document this
somewhere? Maybe a blog posting?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I like your wording, but the "that encoding" wasn't clear enough for me,
so I reworded it to:Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
character available in the database encoding, even when the database
encoding is not UTF-8 (Tom Lane)How about "to be used for" instead of "to represent"? "Represent" kind
of sounds like we're using these on output, which we aren't.
Uh, I think "used for" is worse though, since we are not using it. I
don't get the "output" feel of the word at all.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 12, 2020 at 6:36 AM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, May 11, 2020 at 07:41:55PM -0500, Justin Pryzby wrote:
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
One more observation:
Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
Praliaskouski)
This new behavior allows pages to be set as all-visible, which then
allows index-only scans, ...The above sentence sounds to mean that this feature allows index-only
scans in more number of cases after this feature. Is that what you
intend to say? If so, is that correct? Because I think this will
allow index-only scans to skip "Heap Fetches" in more cases.I think what you mean is that the autovacuum feature, in addition to
encouraging the *planner* to choose an indexonly scan, will *also* allow (at
execution time) fewer heap fetches for a plan which would have
already/previously used IOS. Right ? So maybe it should say "allows OR
IMPROVES index-only scans" or "allows plans which use IOS to run more
efficiently".Yes, I see your point now. New text is:
This new behavior reduces the work necessary when the table
needs to be frozen and allows pages to be set as all-visible.
All-visible pages allow index-only scans to access fewer heap rows.
The next text LGTM. Thanks.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Mon, May 11, 2020 at 10:23:53PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Well, are you suggesting a new section because the glossary shouldn't be
listed under source code, or because you want the function reformatting
added? We just need to understand what the purpose is. We already have
the glossary listed, since that is new and user-visible.The implication of what you say here is that "is it user-visible?"
is a criterion for whether to release-note something. By that logic
we probably *should* relnote the function table layout changes, because
they sure as heck are user-visible. People might or might not notice
addition of a glossary, but I think just about every user consults
the function/operator tables regularly.I concur with Alvaro's position that if we are listing documentation
changes, pushing them under "Source Code" is not the way to do it.
That subsection has always been understood to be "stuff you don't
care about if you're not a hacker".So that sort of leads me to the conclusion that "major documentation
changes" might be a reasonable sub-heading for the release notes.
OK, section and item added, patch attached,
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Attachments:
doc.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 83470e9ba1..34211e2b68 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -2331,7 +2331,7 @@ Use the directory of the pg_upgrade binary as the default new 'bindir' location
</sect3>
<sect3>
- <title>Source Code</title>
+ <title>Documentation</title>
<itemizedlist>
@@ -2347,6 +2347,27 @@ Add a glossary to the documentation (Corey Huinker, Jürgen Purtz, Roger Har
</listitem>
+<listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2020-04-12 [e894c6183] Doc: introduce new layout for tables of functions and op
+-->
+
+<para>
+Reformat tables containing function information for better clarity (Tom Lane)
+</para>
+
+</listitem>
+
+ </itemizedlist>
+
+ </sect3>
+
+ <sect3>
+ <title>Source Code</title>
+
+ <itemizedlist>
+
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
On 2020/05/12 9:34, Bruce Momjian wrote:
Could you add "Vinayak Pokale" as a co-author of the following feature since
I sometimes read his old patch to create a patch [1] ?=======================
E.1.3.1.6. System Views- Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada)
+ Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada, Vinayak Pokale)
=======================Done.
Hi Bruce,
Thank you!
Regards,
Tatsuro Yamada
On Tue, May 12, 2020 at 6:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
1. We have allowed an (auto)vacuum to display additional information
about heap or index in case of an error in commit b61d161c14 [1].
Now, in general, it might not be worth saying much about error
information but I think this one could help users in case they have
some corruption. For example, if one of the indexes on a relation has
some corrupted data (due to bad hardware or some bug), it will let the
user know the index information, and the user can take appropriate
action like either Reindex or maybe drop and recreate the index to
overcome the problem.I'm not opposed to including it, but I think it's still true that the user
doesn't need to know in advance that the error message will be additionally
helpful in the event of corruption. If we were to include more "error" items,
we might also include these:71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
17a28b03645e27d73bf69a95d7569b61e58f06eb Improve the internal implementation of ereport().
05f18c6b6b6e4b44302ee20a042cedc664532aa2 Added relation name in error messages for constraint checks.
33753ac9d7bc83dd9ccee9d5e678ed78a0725b4e Add object names to partition integrity violations.
I think the first one (Add backtrace support for error reporting)
seems to be quite useful as it can help to detect the problems faster.
I think having a simple rule as Bruce has w.r.t "error messages" makes
it easier to decide whether to take a particular commit or not but I
feel some of these could help users to know the new functionality and
might encourage them to upgrade to the new version. Sure, nobody is
going to move due to only these features but along with other things,
improved error handling is a good thing to know.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On 05/11/20 22:48, Bruce Momjian wrote:
On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
character available in the database encoding, even when the database
encoding is not UTF-8 (Tom Lane)How about "to be used for" instead of "to represent"? "Represent" kind
of sounds like we're using these on output, which we aren't.Uh, I think "used for" is worse though, since we are not using it. I
don't get the "output" feel of the word at all.
'specify' ?
-Chap
On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
On 05/11/20 22:48, Bruce Momjian wrote:
On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
character available in the database encoding, even when the database
encoding is not UTF-8 (Tom Lane)How about "to be used for" instead of "to represent"? "Represent" kind
of sounds like we're using these on output, which we aren't.Uh, I think "used for" is worse though, since we are not using it. I
don't get the "output" feel of the word at all.'specify' ?
I like that word if Tom prefers it.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Bruce Momjian <bruce@momjian.us> writes:
On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
'specify' ?
I like that word if Tom prefers it.
'specify' works for me.
regards, tom lane
At Mon, 11 May 2020 20:12:04 -0400, Bruce Momjian <bruce@momjian.us> wrote in
On Thu, May 7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
- Crash recovery was losing tuples written via COPY TO. This fixes the bug.
This was not backpatched?
Right.
Oh. So you are saying we could lose COPY data on a crash, even after a
commit. That seems bad. Can you show me the commit info? I can't find
it.commit c6b9204
Author: Noah Misch <noah@leadboat.com>
AuthorDate: Sat Apr 4 12:25:34 2020 -0700
Commit: Noah Misch <noah@leadboat.com>
CommitDate: Sat Apr 4 12:25:34 2020 -0700Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.OK, so how do we want to document this? Do I mention in the text below
the WAL skipping item that this fixes a bug where a mix of simultaneous
COPY and INSERT into a table could lose rows during crash recovery, or
create a new item?
FWIW, as dicussed upthread, I suppose that the API change is not going
to be in relnotes.
something like this?
- Fix bug of WAL-skipping optimiazation
Previously a trasaction doing both of COPY and a WAL-logged operations
like INSERT while wal_level=minimal can lead to loss of COPY'ed rows
through crash recovery. Also this fix extends the WAL-skipping
optimiazation to all kinds of bulk insert operations.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Hello Bruce,
OK, section and item added, patch attached,
Thanks!
Some items that might be considered for the added documentation section:
* e1ff780485
* 34a0a81bfb
* e829337d42
* "Document color support (Peter Eisentraut)"
THIS WAS NOT DOCUMENTED BEFORE?
Not as such, AFAICR it was vaguely hinted about in the documentation of
command that would use it, but not even all of them. Now there is a new
specific section.
--
Fabien!
On 2020-May-07, Bruce Momjian wrote:
OK, I have moved her name to be first. FYI, this commit was backpatched
back through PG 11, though the commit message doesn't mention that.
At some point I became an avid user of our src/tools/git_changelog, and
then it stopped making sense for me to highlight in the commit message
the fact that the commit is back-patched, since it's so obvious there.
Maybe that's wrong and I should get back in the habit of mentioning it.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, May 11, 2020 at 11:38:33PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
'specify' ?
I like that word if Tom prefers it.
'specify' works for me.
Sure, done.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
commit c6b9204
Author: Noah Misch <noah@leadboat.com>
AuthorDate: Sat Apr 4 12:25:34 2020 -0700
Commit: Noah Misch <noah@leadboat.com>
CommitDate: Sat Apr 4 12:25:34 2020 -0700Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.OK, so how do we want to document this? Do I mention in the text below
the WAL skipping item that this fixes a bug where a mix of simultaneous
COPY and INSERT into a table could lose rows during crash recovery, or
create a new item?FWIW, as dicussed upthread, I suppose that the API change is not going
to be in relnotes.something like this?
- Fix bug of WAL-skipping optimiazation
Previously a trasaction doing both of COPY and a WAL-logged operations
like INSERT while wal_level=minimal can lead to loss of COPY'ed rows
through crash recovery. Also this fix extends the WAL-skipping
optimiazation to all kinds of bulk insert operations.
Uh, that kind of mixes the bug fix and the feature in a way that it is
hard to understand. How about this?
Allow skipping of WAL for new tables and indexes if wal_level is
'minimal' (Kyotaro Horiguchi)
Relations larger than wal_skip_threshold will have their files
fsync'ed rather than writing their WAL records. Previously this
was done only for COPY operations, but the implementation had a
bug that could cause data loss during crash recovery.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 12, 2020 at 09:43:10AM +0200, Fabien COELHO wrote:
Hello Bruce,
OK, section and item added, patch attached,
Thanks!
Some items that might be considered for the added documentation section:
* e1ff780485
I was told in this email thread to not include that one.
* 34a0a81bfb
We already have:
Reformat tables containing function information for better
clarity (Tom Lane)
so it seems it is covered as part of this.
* e829337d42
Uh, this is a doc link formatting addition. I think this falls into the
error message logic, where it is nice when people want it, but they
don't need to know about it ahead of time.
* "Document color support (Peter Eisentraut)"
THIS WAS NOT DOCUMENTED BEFORE?Not as such, AFAICR it was vaguely hinted about in the documentation of
command that would use it, but not even all of them. Now there is a new
specific section.
Again, this is the first hash you gave.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Tue, May 12, 2020 at 01:47:38PM -0400, Alvaro Herrera wrote:
On 2020-May-07, Bruce Momjian wrote:
OK, I have moved her name to be first. FYI, this commit was backpatched
back through PG 11, though the commit message doesn't mention that.At some point I became an avid user of our src/tools/git_changelog, and
then it stopped making sense for me to highlight in the commit message
the fact that the commit is back-patched, since it's so obvious there.
Maybe that's wrong and I should get back in the habit of mentioning it.
Uh, not sure. I don't need it since, as you said,
src/tools/git_changelog covers it, but someone got confused since they
looked at just the commit message without looking at
src/tools/git_changelog.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +At Tue, 12 May 2020 16:38:09 -0400, Bruce Momjian <bruce@momjian.us> wrote in
On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
commit c6b9204
Author: Noah Misch <noah@leadboat.com>
AuthorDate: Sat Apr 4 12:25:34 2020 -0700
Commit: Noah Misch <noah@leadboat.com>
CommitDate: Sat Apr 4 12:25:34 2020 -0700Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.OK, so how do we want to document this? Do I mention in the text below
the WAL skipping item that this fixes a bug where a mix of simultaneous
COPY and INSERT into a table could lose rows during crash recovery, or
create a new item?FWIW, as dicussed upthread, I suppose that the API change is not going
to be in relnotes.something like this?
- Fix bug of WAL-skipping optimiazation
Previously a trasaction doing both of COPY and a WAL-logged operations
like INSERT while wal_level=minimal can lead to loss of COPY'ed rows
through crash recovery. Also this fix extends the WAL-skipping
optimiazation to all kinds of bulk insert operations.Uh, that kind of mixes the bug fix and the feature in a way that it is
hard to understand. How about this?Allow skipping of WAL for new tables and indexes if wal_level is
'minimal' (Kyotaro Horiguchi)Relations larger than wal_skip_threshold will have their files
fsync'ed rather than writing their WAL records. Previously this
was done only for COPY operations, but the implementation had a
bug that could cause data loss during crash recovery.
I see it. It is giving weight on improvement. Looks good the overall
structure of the description above. However, wal-skipping is always
done regardless of table size. wal_skip_threshold is an optimization
to choose which to use fsync or FPI records (that is, not WAL records
in the common sense) at commit for speed.
So how about the following?
All kinds of bulk-insertion are not WAL-logged then fsync'ed at
commit. Using FPI WAL records instead of fsync for relations smaller
than wal_skip_threshold. Previously this was done only for COPY
operations and always using fsync, but the implementation had a bug
that could cause data loss during crash recovery.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Hello Bruce,
* e1ff780485
I was told in this email thread to not include that one.
Ok.
* 34a0a81bfb
We already have:
Reformat tables containing function information for better
clarity (Tom Lane)so it seems it is covered as part of this.
AFAICR this one is not by the same author, and although the point was
about better clarity, it was not about formating but rather about
restructuring text vs binary string function documentations. Then Tom
reformatted the result.
* e829337d42
Uh, this is a doc link formatting addition. I think this falls into the
error message logic, where it is nice when people want it, but they
don't need to know about it ahead of time.
Hmmm. ISTM that this is not really about "error message logic", it is
about navigating to libpq functions when one is reference in the
description of another to check what it does, which I had to do a lot
while developing some performance testing code for a project.
* "Document color support (Peter Eisentraut)"
THIS WAS NOT DOCUMENTED BEFORE?Not as such, AFAICR it was vaguely hinted about in the documentation of
command that would use it, but not even all of them. Now there is a new
specific section.Again, this is the first hash you gave.
Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to
still be in the release notes, I gathered that the information had not
reached its destination, hence the possible repetition. But maybe the
issue is that this answer is not satisfactory. Sorry for the
inconvenience.
--
Fabien.
On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
Allow skipping of WAL for new tables and indexes if wal_level is
'minimal' (Kyotaro Horiguchi)Relations larger than wal_skip_threshold will have their files
fsync'ed rather than writing their WAL records. Previously this
was done only for COPY operations, but the implementation had a
bug that could cause data loss during crash recovery.I see it. It is giving weight on improvement. Looks good the overall
structure of the description above. However, wal-skipping is always
done regardless of table size. wal_skip_threshold is an optimization
to choose which to use fsync or FPI records (that is, not WAL records
in the common sense) at commit for speed.
Well, as far as users are concerned, everything wrtiten to WAL is a WAL
record.
So how about the following?
All kinds of bulk-insertion are not WAL-logged then fsync'ed at
commit. Using FPI WAL records instead of fsync for relations smaller
than wal_skip_threshold. Previously this was done only for COPY
operations and always using fsync, but the implementation had a bug
that could cause data loss during crash recovery.
That is too much detail for the release notes. We already will link to
the docs. Why put it here?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Wed, May 13, 2020 at 07:18:38AM +0200, Fabien COELHO wrote:
Hello Bruce,
* e1ff780485
I was told in this email thread to not include that one.
Ok.
* 34a0a81bfb
We already have:
Reformat tables containing function information for better
clarity (Tom Lane)so it seems it is covered as part of this.
AFAICR this one is not by the same author, and although the point was about
better clarity, it was not about formating but rather about restructuring
text vs binary string function documentations. Then Tom reformatted the
result.
Well, we were not even clear we should document changes in the functions
section, so going into details of all the changes seems unwise.
* e829337d42
Uh, this is a doc link formatting addition. I think this falls into the
error message logic, where it is nice when people want it, but they
don't need to know about it ahead of time.Hmmm. ISTM that this is not really about "error message logic", it is about
navigating to libpq functions when one is reference in the description of
another to check what it does, which I had to do a lot while developing some
performance testing code for a project.
I don't see it.
* "Document color support (Peter Eisentraut)"
THIS WAS NOT DOCUMENTED BEFORE?Not as such, AFAICR it was vaguely hinted about in the documentation of
command that would use it, but not even all of them. Now there is a new
specific section.Again, this is the first hash you gave.
Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to
still be in the release notes, I gathered that the information had not
reached its destination, hence the possible repetition. But maybe the issue
is that this answer is not satisfactory. Sorry for the inconvenience.
I removed it already based on feedback from someone else.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian <bruce@momjian.us> wrote in
On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
Allow skipping of WAL for new tables and indexes if wal_level is
'minimal' (Kyotaro Horiguchi)Relations larger than wal_skip_threshold will have their files
fsync'ed rather than writing their WAL records. Previously this
was done only for COPY operations, but the implementation had a
bug that could cause data loss during crash recovery.I see it. It is giving weight on improvement. Looks good the overall
structure of the description above. However, wal-skipping is always
done regardless of table size. wal_skip_threshold is an optimization
to choose which to use fsync or FPI records (that is, not WAL records
in the common sense) at commit for speed.Well, as far as users are concerned, everything wrtiten to WAL is a WAL
record.
I think that the significant point here is not that persistence is
ensured by which of fsync or WAL , but whether WAL records are written
for every insertion. The commit-time WA is just an alternative of
fsync, which is faster than fsync'ing separate files for smaller
files.
So how about the following?
All kinds of bulk-insertion are not WAL-logged then fsync'ed at
commit. Using FPI WAL records instead of fsync for relations smaller
than wal_skip_threshold. Previously this was done only for COPY
operations and always using fsync, but the implementation had a bug
that could cause data loss during crash recovery.That is too much detail for the release notes. We already will link to
the docs. Why put it here?
It is just an more accurate (not an detailed) version of the
previously proposed description. If we simplify that, I choose to
remove explanation on wal_skip_threshold.
How about this?
WAL-logging is now skipped while all kinds of bulk-insertion, then
relations are sync'ed to disk at commit. Previously this was done
only for COPY operations, but the implementation had a bug that could
cause data loss during crash recovery.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian <bruce@momjian.us> wrote in
On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
It is just an more accurate (not an detailed) version of the
previously proposed description. If we simplify that, I choose to
remove explanation on wal_skip_threshold.How about this?
WAL-logging is now skipped while all kinds of bulk-insertion, then
relations are sync'ed to disk at commit. Previously this was done
only for COPY operations, but the implementation had a bug that could
cause data loss during crash recovery.
OK, I went with this text, stating WAL "generation" is skipped:
Allow skipping of WAL for full table writes if wal_level is 'minimal'
(Kyotaro Horiguchi)
Relations larger than wal_skip_threshold will have their files
fsync'ed rather than generating WAL. Previously this was done
only for COPY operations, but the implementation had a bug that
could cause data loss during crash recovery.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Hello Bruce,
* 34a0a81bfb
We already have:
Reformat tables containing function information for better
clarity (Tom Lane)so it seems it is covered as part of this.
AFAICR this one is not by the same author, and although the point was about
better clarity, it was not about formating but rather about restructuring
text vs binary string function documentations. Then Tom reformatted the
result.Well, we were not even clear we should document changes in the functions
section, so going into details of all the changes seems unwise.
The restructuring was a significant change, and ISTM that another function
of the release note is also to implicitely thank contributors (their name
is appended, which does not bring any useful information about the feature
from a release note perspective) hence my suggestion to include this one,
the author of which is not Tom Lane.
* e829337d42
Uh, this is a doc link formatting addition. I think this falls into the
error message logic, where it is nice when people want it, but they
don't need to know about it ahead of time.[...]
I don't see it.
While reading again the sequence, ISTM that I did not understand your
first answer, so my answer was kind-of off topic, sorry. This is indeed
"link formatting addition", which helps making the libpq doc more usable.
Probably you do not need to know about it in advance, but I do not think
that it is a good reason not to include it: with the same argument, a
performance improvement would not need to be advertise, you'll see it when
you need it. The same holds for all non-functional improvements, and there
are many which are listed.
Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to
still be in the release notes, I gathered that the information had not
reached its destination, hence the possible repetition. But maybe the issue
is that this answer is not satisfactory. Sorry for the inconvenience.I removed it already based on feedback from someone else.
Good. I looked at the online version which is off the latest commits by a
few hours.
I'd consider moving "Upgrade to use DocBook 4.5 (Peter Eisentraut)" to the
doc section, maybe.
--
Fabien.
At Wed, 13 May 2020 22:40:52 -0400, Bruce Momjian <bruce@momjian.us> wrote in
On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian <bruce@momjian.us> wrote in
On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
It is just an more accurate (not an detailed) version of the
previously proposed description. If we simplify that, I choose to
remove explanation on wal_skip_threshold.How about this?
WAL-logging is now skipped while all kinds of bulk-insertion, then
relations are sync'ed to disk at commit. Previously this was done
only for COPY operations, but the implementation had a bug that could
cause data loss during crash recovery.OK, I went with this text, stating WAL "generation" is skipped:
Allow skipping of WAL for full table writes if wal_level is 'minimal'
(Kyotaro Horiguchi)Relations larger than wal_skip_threshold will have their files
fsync'ed rather than generating WAL. Previously this was done
only for COPY operations, but the implementation had a bug that
could cause data loss during crash recovery.
Although I can't help feeling it out-of-point a bit, it is right in
apperarance. So, I don't object it.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Thu, May 14, 2020 at 07:23:05AM +0200, Fabien COELHO wrote:
Hello Bruce,
* 34a0a81bfb
We already have:
Reformat tables containing function information for better
clarity (Tom Lane)so it seems it is covered as part of this.
AFAICR this one is not by the same author, and although the point was about
better clarity, it was not about formating but rather about restructuring
text vs binary string function documentations. Then Tom reformatted the
result.Well, we were not even clear we should document changes in the functions
section, so going into details of all the changes seems unwise.The restructuring was a significant change, and ISTM that another function
of the release note is also to implicitely thank contributors (their name is
appended, which does not bring any useful information about the feature from
a release note perspective) hence my suggestion to include this one,
the author of which is not Tom Lane.
We list people's names next to items. We don't list items to list
people's names, as far as I know of the policy. If you want to change
that, you will need to start a new thread and get agreement.
* e829337d42
Uh, this is a doc link formatting addition. I think this falls into the
error message logic, where it is nice when people want it, but they
don't need to know about it ahead of time.[...]
I don't see it.
While reading again the sequence, ISTM that I did not understand your first
answer, so my answer was kind-of off topic, sorry. This is indeed "link
formatting addition", which helps making the libpq doc more usable.
Probably you do not need to know about it in advance, but I do not think
that it is a good reason not to include it: with the same argument, a
performance improvement would not need to be advertise, you'll see it when
you need it. The same holds for all non-functional improvements, and there
are many which are listed.
Peformance items are listed only if they will produce a visible change
in performance, or enable new workloads that were too slow in the past.
Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to
still be in the release notes, I gathered that the information had not
reached its destination, hence the possible repetition. But maybe the issue
is that this answer is not satisfactory. Sorry for the inconvenience.I removed it already based on feedback from someone else.
Good. I looked at the online version which is off the latest commits by a
few hours.I'd consider moving "Upgrade to use DocBook 4.5 (Peter Eisentraut)" to the
doc section, maybe.
Agreed, done.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On 2020-05-12 02:41, Justin Pryzby wrote:
I'm not opposed to including it, but I think it's still true that the user
doesn't need to know in advance that the error message will be additionally
helpful in the event of corruption. If we were to include more "error" items,
we might also include these:71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
This is actually a legitimate user-visible feature and should be listed
somewhere.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, May 14, 2020 at 2:02 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
On 2020-05-12 02:41, Justin Pryzby wrote:
I'm not opposed to including it, but I think it's still true that the user
doesn't need to know in advance that the error message will be additionally
helpful in the event of corruption. If we were to include more "error" items,
we might also include these:71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
This is actually a legitimate user-visible feature and should be listed
somewhere.
+1 -- it's very handy. Plus it has user-facing knobs.
--
Peter Geoghegan
On Thu, May 14, 2020 at 11:01:51PM +0200, Peter Eisentraut wrote:
On 2020-05-12 02:41, Justin Pryzby wrote:
I'm not opposed to including it, but I think it's still true that the user
doesn't need to know in advance that the error message will be additionally
helpful in the event of corruption. If we were to include more "error" items,
we might also include these:71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
This is actually a legitimate user-visible feature and should be listed
somewhere.
On Thu, May 14, 2020 at 02:02:52PM -0700, Peter Geoghegan wrote:
+1 -- it's very handy. Plus it has user-facing knobs.
That's already included:
| Allow function call backtraces of errors to be logged (Peter Eisentraut, �lvaro Herrera)
| Server variable backtrace_functions specifies which C functions should generate backtraces on error.
I 1) I failed to double check my list; and, 2) intended for that to be
interpretted as items which could be moved to a separate "error reporting"
section of the release notes.
--
Justin
Import Notes
Reply to msg id not found: CAH2-WzmMq+53zOn+6VDhSHj2pa9mn0MLGx1KE3u38sP0ObD9g@mail.gmail.com08a50ae9-89fe-a29b-c4e4-0fb5033c2f06@2ndquadrant.com | Resolved by subject fallback
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Many thanks for working on this!
When I did "make html", I got the following message.
Link element has no content and no Endterm. Nothing to show in the link to sepgsql
"Allow <link linkend="sepgsql"/> to control access to the" in release-13.sgml
seems to have caused this. Also I found it's converted into "Allow ??? to
control access to the", i.e., ??? was used.
- Allow <link linkend="sepgsql"/> to control access to the
+ Allow <link linkend="sepgsql">sepgsql</link> to control access to theShouldn't we change that as the above?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On Fri, May 15, 2020 at 03:55:19PM +0900, Fujii Masao wrote:
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Many thanks for working on this!
When I did "make html", I got the following message.
Link element has no content and no Endterm. Nothing to show in the link to sepgsql
"Allow <link linkend="sepgsql"/> to control access to the" in release-13.sgml
seems to have caused this. Also I found it's converted into "Allow ??? to
control access to the", i.e., ??? was used.- Allow <link linkend="sepgsql"/> to control access to the + Allow <link linkend="sepgsql">sepgsql</link> to control access to theShouldn't we change that as the above?
Actually, it should be:
<xref linkend="sepgsql"/>
because we are using the text from the link. See
doc/src/sgml/README.links for details on xref links. Release notes
updated. Odd I got no warning for this on 'make check'.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On 2020/05/15 21:29, Bruce Momjian wrote:
On Fri, May 15, 2020 at 03:55:19PM +0900, Fujii Masao wrote:
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.Many thanks for working on this!
When I did "make html", I got the following message.
Link element has no content and no Endterm. Nothing to show in the link to sepgsql
"Allow <link linkend="sepgsql"/> to control access to the" in release-13.sgml
seems to have caused this. Also I found it's converted into "Allow ??? to
control access to the", i.e., ??? was used.- Allow <link linkend="sepgsql"/> to control access to the + Allow <link linkend="sepgsql">sepgsql</link> to control access to theShouldn't we change that as the above?
Actually, it should be:
<xref linkend="sepgsql"/>
because we are using the text from the link.
Yes, this works.
See
doc/src/sgml/README.links for details on xref links. Release notes
updated.
Thanks!
Odd I got no warning for this on 'make check'.
I'm not sure why, but btw I got the message when I compiled the document on Mac.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On Fri, May 15, 2020 at 09:54:55PM +0900, Fujii Masao wrote:
Actually, it should be:
<xref linkend="sepgsql"/>
because we are using the text from the link.
Yes, this works.
See
doc/src/sgml/README.links for details on xref links. Release notes
updated.Thanks!
Odd I got no warning for this on 'make check'.
I'm not sure why, but btw I got the message when I compiled the document on Mac.
I don't think I looked at the HTML build output, only the check one, so
that might be the cause.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On 5 May 2020, at 05:16, Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:
Spotted a typo we probably should fix: s/PostgresSQL/PostgreSQL/ =)
cheers ./daniel
Attachments:
13relnotes_postgressql.diffapplication/octet-stream; name=13relnotes_postgressql.diff; x-unix-mode=0644Download
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index c39a6ad38e..7f864da162 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -215,7 +215,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
<para>
Remove support for defining <link linkend="sql-createopclass">operator
- classes</link> using pre-<productname>PostgresSQL</productname>
+ classes</link> using pre-<productname>PostgreSQL</productname>
8.0 syntax (Daniel Gustafsson)
</para>
</listitem>
@@ -228,7 +228,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
<para>
Remove support for defining <link linkend="sql-altertable">foreign key
- constraints</link> using pre-<productname>PostgresSQL</productname>
+ constraints</link> using pre-<productname>PostgreSQL</productname>
7.3 syntax (Daniel Gustafsson)
</para>
</listitem>
@@ -242,7 +242,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
<para>
Remove support for "opaque" <link
linkend="sql-createtype">pseudo-types</link> used by
- pre-<productname>PostgresSQL</productname> 7.3 servers (Daniel
+ pre-<productname>PostgreSQL</productname> 7.3 servers (Daniel
Gustafsson)
</para>
</listitem>
Thanks, applied.
---------------------------------------------------------------------------
On Mon, May 18, 2020 at 11:18:51AM +0200, Daniel Gustafsson wrote:
On 5 May 2020, at 05:16, Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:Spotted a typo we probably should fix: s/PostgresSQL/PostgreSQL/ =)
cheers ./daniel
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml index c39a6ad38e..7f864da162 100644 --- a/doc/src/sgml/release-13.sgml +++ b/doc/src/sgml/release-13.sgml @@ -215,7 +215,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us><para> Remove support for defining <link linkend="sql-createopclass">operator - classes</link> using pre-<productname>PostgresSQL</productname> + classes</link> using pre-<productname>PostgreSQL</productname> 8.0 syntax (Daniel Gustafsson) </para> </listitem> @@ -228,7 +228,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us><para> Remove support for defining <link linkend="sql-altertable">foreign key - constraints</link> using pre-<productname>PostgresSQL</productname> + constraints</link> using pre-<productname>PostgreSQL</productname> 7.3 syntax (Daniel Gustafsson) </para> </listitem> @@ -242,7 +242,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us> <para> Remove support for "opaque" <link linkend="sql-createtype">pseudo-types</link> used by - pre-<productname>PostgresSQL</productname> 7.3 servers (Daniel + pre-<productname>PostgreSQL</productname> 7.3 servers (Daniel Gustafsson) </para> </listitem>
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Spotted this in the release notes:
<para>
Add extension <application>bool_plperl</application> which transforms
<acronym>SQL</acronym> booleans to/from PL/Perl booleans (Ivan
Panchenko) WHERE IS THIS DOCUMENTED?
</para>
bool_plperl is documented in "44.1. PL/Perl Functions and Arguments", but not
with a separate section (which fwiw I don't disagree with). Linking there from
the release notes entry would require some rewriting to make it fit; I would
just remove the placeholder question for this one.
cheers ./daniel
On Mon, May 25, 2020 at 10:54:03AM +0200, Daniel Gustafsson wrote:
Spotted this in the release notes:
<para>
Add extension <application>bool_plperl</application> which transforms
<acronym>SQL</acronym> booleans to/from PL/Perl booleans (Ivan
Panchenko) WHERE IS THIS DOCUMENTED?
</para>bool_plperl is documented in "44.1. PL/Perl Functions and Arguments", but not
with a separate section (which fwiw I don't disagree with). Linking there from
the release notes entry would require some rewriting to make it fit; I would
just remove the placeholder question for this one.
Thanks, done.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Hi,
I realized that PG 13 release note still has the following entry:
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
-->
<para>
Add <literal>FOREIGN</literal> to <command>ALTER</command> statements,
if appropriate (Luis Carril)
</para>
<para>
WHAT IS THIS ABOUT?
</para>
</listitem>
</itemizedlist>
IIUC this entry is about that pg_dump adds FOREIGN word to ALTER TABLE
command. Please find the attached patch.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
pg13_release_note.patchapplication/octet-stream; name=pg13_release_note.patchDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 401c557373..c8fb4f0f21 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -1534,22 +1534,6 @@ Author: Peter Eisentraut <peter@eisentraut.org>
</para>
</listitem>
- <listitem>
-<!--
-Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
-2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
--->
-
- <para>
- Add <literal>FOREIGN</literal> to <command>ALTER</command> statements,
- if appropriate (Luis Carril)
- </para>
-
- <para>
- WHAT IS THIS ABOUT?
- </para>
- </listitem>
-
</itemizedlist>
</sect3>
@@ -2423,6 +2407,19 @@ Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
<listitem>
<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
+-->
+
+ <para>
+ <link linkend="app-pgdump"><application>pg_dump</application></link>
+ adds <literal>FOREIGN</literal> to <command>ALTER</command> statements,
+ if appropriate (Luis Carril)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
Author: Amit Kapila <akapila@postgresql.org>
2020-01-29 [47bc9ced0] Add - -parallel option to vacuumdb command.
-->
On Fri, Jun 26, 2020 at 05:24:16PM +0900, Masahiko Sawada wrote:
Hi,
I realized that PG 13 release note still has the following entry:
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
--><para>
Add <literal>FOREIGN</literal> to <command>ALTER</command> statements,
if appropriate (Luis Carril)
</para><para>
WHAT IS THIS ABOUT?
</para>
</listitem></itemizedlist>
IIUC this entry is about that pg_dump adds FOREIGN word to ALTER TABLE
command. Please find the attached patch.
OK, so if that is, what used to happen before? Did it still work
without the FOREIGN keyword? If so, I am thinking we should just remove
this item.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On 2020-Jun-26, Bruce Momjian wrote:
On Fri, Jun 26, 2020 at 05:24:16PM +0900, Masahiko Sawada wrote:
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
--><para>
Add <literal>FOREIGN</literal> to <command>ALTER</command> statements,
if appropriate (Luis Carril)
</para>
IIUC this entry is about that pg_dump adds FOREIGN word to ALTER TABLE
command. Please find the attached patch.OK, so if that is, what used to happen before? Did it still work
without the FOREIGN keyword? If so, I am thinking we should just remove
this item.
I tend to agree, it's not a change significant enough to be documented
in the relnotes, i think.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reading Luis Carril's other entry in the relnotes,
Allow pg_dump --include-foreign-data to dump data from foreign servers (Luis Carril)
It seems to suggest that --include-foreign-data existed previously,
which is not true. I would have worded it as "Add --include-foreign-data
option to pg_dump to allow dumping data from foreign servers".
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Jun 26, 2020 at 04:23:26PM -0400, Alvaro Herrera wrote:
Reading Luis Carril's other entry in the relnotes,
Allow pg_dump --include-foreign-data to dump data from foreign servers (Luis Carril)
It seems to suggest that --include-foreign-data existed previously,
which is not true. I would have worded it as "Add --include-foreign-data
option to pg_dump to allow dumping data from foreign servers".
OK, pg_dump item about FOREIGN keyword removed from PG 13 release notes,
and the above item clarified. Patch attached and applied to PG 13.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Attachments:
foreign.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
new file mode 100644
index 401c557..45d8f0b
*** a/doc/src/sgml/release-13.sgml
--- b/doc/src/sgml/release-13.sgml
*************** Author: Peter Eisentraut <peter@eisentra
*** 1534,1555 ****
</para>
</listitem>
- <listitem>
- <!--
- Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
- 2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
- -->
-
- <para>
- Add <literal>FOREIGN</literal> to <command>ALTER</command> statements,
- if appropriate (Luis Carril)
- </para>
-
- <para>
- WHAT IS THIS ABOUT?
- </para>
- </listitem>
-
</itemizedlist>
</sect3>
--- 1534,1539 ----
*************** Author: Alvaro Herrera <alvherre@alvh.no
*** 2414,2423 ****
-->
<para>
! Allow <link
linkend="app-pgdump"><application>pg_dump</application></link>
! <option>--include-foreign-data</option> to dump data from foreign
! servers (Luis Carril)
</para>
</listitem>
--- 2398,2407 ----
-->
<para>
! Add <link
linkend="app-pgdump"><application>pg_dump</application></link>
! option <option>--include-foreign-data</option> to dump data from
! foreign servers (Luis Carril)
</para>
</listitem>
Hi Bruce,
On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian <bruce@momjian.us> wrote:
Patch attached and applied to PG 13.
I committed the hash_mem_multiplier GUC to Postgres 13 just now.
There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash aggregation
to use disk storage for large aggregation result sets" feature should
reference the new GUC directly. Users should be advised that the GUC
may be useful in cases where they upgrade and experience a performance
regression linked to slower hash aggregation. Just including a
documentation link for the GUC would be very helpful.
Thanks
--
Peter Geoghegan
On Wed, Jul 29, 2020 at 03:34:22PM -0700, Peter Geoghegan wrote:
Hi Bruce,
On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian <bruce@momjian.us> wrote:
Patch attached and applied to PG 13.
I committed the hash_mem_multiplier GUC to Postgres 13 just now.
There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash aggregation
to use disk storage for large aggregation result sets" feature should
reference the new GUC directly. Users should be advised that the GUC
may be useful in cases where they upgrade and experience a performance
regression linked to slower hash aggregation. Just including a
documentation link for the GUC would be very helpful.
I came up with the attached patch.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Attachments:
hash.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
new file mode 100644
index 18e6497..2586645
*** a/doc/src/sgml/release-13.sgml
--- b/doc/src/sgml/release-13.sgml
*************** Author: Jeff Davis <jdavis@postgresql.or
*** 649,655 ****
<para>
Previously, hash aggregation was avoided if it was expected to use
! more than <xref linkend="guc-work-mem"/> memory.
</para>
</listitem>
--- 649,657 ----
<para>
Previously, hash aggregation was avoided if it was expected to use
! more than <xref linkend="guc-work-mem"/> memory. To use more
! memory for hash query operations, increase <xref
! linkend="guc-hash-mem-multiplier"/>.
</para>
</listitem>
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash aggregation
to use disk storage for large aggregation result sets" feature should
reference the new GUC directly. Users should be advised that the GUC
may be useful in cases where they upgrade and experience a performance
regression linked to slower hash aggregation. Just including a
documentation link for the GUC would be very helpful.I came up with the attached patch.
I was thinking something along like the following (after the existing
sentence about avoiding hash aggs in the planner):
If you find that hash aggregation is slower than in previous major
releases of PostgreSQL, it may be useful to increase the value of
hash_mem_multiplier. This allows hash aggregation to use more memory
without affecting competing query operations that are generally less
likely to put any additional memory to good use.
--
Peter Geoghegan
On Wed, Jul 29, 2020 at 07:00:43PM -0700, Peter Geoghegan wrote:
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash aggregation
to use disk storage for large aggregation result sets" feature should
reference the new GUC directly. Users should be advised that the GUC
may be useful in cases where they upgrade and experience a performance
regression linked to slower hash aggregation. Just including a
documentation link for the GUC would be very helpful.I came up with the attached patch.
I was thinking something along like the following (after the existing
sentence about avoiding hash aggs in the planner):If you find that hash aggregation is slower than in previous major
releases of PostgreSQL, it may be useful to increase the value of
hash_mem_multiplier. This allows hash aggregation to use more memory
without affecting competing query operations that are generally less
likely to put any additional memory to good use.
Well, that seems to be repeating what is already in the docs for
hash_mem_multiplier, which I try to avoid. One other direction is to
put something in the incompatibilities section. Does that make sense?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Wed, Jul 29, 2020 at 7:48 PM Bruce Momjian <bruce@momjian.us> wrote:
Well, that seems to be repeating what is already in the docs for
hash_mem_multiplier, which I try to avoid. One other direction is to
put something in the incompatibilities section. Does that make sense?
I would prefer to put it next to the hash agg item itself. It's more
likely to be noticed there, and highlighting it a little seems
warranted.
OTOH, this may not be a problem at all for many individual users.
Framing it as a tip rather than a compatibility item gets that across.
--
Peter Geoghegan
On Wednesday, July 29, 2020, Peter Geoghegan <pg@bowt.ie> wrote:
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash aggregation
to use disk storage for large aggregation result sets" feature should
reference the new GUC directly. Users should be advised that the GUC
may be useful in cases where they upgrade and experience a performance
regression linked to slower hash aggregation. Just including a
documentation link for the GUC would be very helpful.I came up with the attached patch.
I was thinking something along like the following (after the existing
sentence about avoiding hash aggs in the planner):If you find that hash aggregation is slower than in previous major
releases of PostgreSQL, it may be useful to increase the value of
hash_mem_multiplier. This allows hash aggregation to use more memory
without affecting competing query operations that are generally less
likely to put any additional memory to good use.
How about adding wording for GROUP BY as well to cater to users who are
more comfortable thinking in terms of SQL statements instead of execution
plans?
David J.
On Wed, Jul 29, 2020 at 08:43:24PM -0700, David G. Johnston wrote:
On Wednesday, July 29, 2020, Peter Geoghegan <pg@bowt.ie> wrote:
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash aggregation
to use disk storage for large aggregation result sets" feature should
reference the new GUC directly. Users should be advised that the GUC
may be useful in cases where they upgrade and experience a performance
regression linked to slower hash aggregation. Just including a
documentation link for the GUC would be very helpful.I came up with the attached patch.
I was thinking something along like the following (after the existing
sentence about avoiding hash aggs in the planner):If you find that hash aggregation is slower than in previous major
releases of PostgreSQL, it may be useful to increase the value of
hash_mem_multiplier. This allows hash aggregation to use more memory
without affecting competing query operations that are generally less
likely to put any additional memory to good use.
I came up with a more verbose documentation suggestion, attached.
How about adding wording for GROUP BY as well to cater to users who are more
comfortable thinking in terms of SQL statements instead of execution plans?
Uh, it is unclear exactly what SQL generates what node types, so I want
to avoid this.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Attachments:
13_hash.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
new file mode 100644
index 18e6497..0b1051b
*** a/doc/src/sgml/release-13.sgml
--- b/doc/src/sgml/release-13.sgml
*************** Author: Jeff Davis <jdavis@postgresql.or
*** 649,655 ****
<para>
Previously, hash aggregation was avoided if it was expected to use
! more than <xref linkend="guc-work-mem"/> memory.
</para>
</listitem>
--- 649,658 ----
<para>
Previously, hash aggregation was avoided if it was expected to use
! more than <xref linkend="guc-work-mem"/> memory. To reduce the
! likelihood of using disk storage for hash aggregation and attain
! behavior similar to previous Postgres releases, increase <xref
! linkend="guc-hash-mem-multiplier"/>.
</para>
</listitem>
On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian <bruce@momjian.us> wrote:
I came up with a more verbose documentation suggestion, attached.
I'm okay with this.
Thanks
--
Peter Geoghegan
On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan <pg@bowt.ie> wrote:
On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian <bruce@momjian.us> wrote:
I came up with a more verbose documentation suggestion, attached.
I'm okay with this.
Are you going to push this soon, Bruce?
--
Peter Geoghegan
On Mon, Aug 3, 2020 at 11:35:50AM -0700, Peter Geoghegan wrote:
On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan <pg@bowt.ie> wrote:
On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian <bruce@momjian.us> wrote:
I came up with a more verbose documentation suggestion, attached.
I'm okay with this.
Are you going to push this soon, Bruce?
Done.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
There's some obvious improvements for which I include a patch.
Add alternate version of jsonb_setI() with special NULL handling (Andrew Dunstan)
The new function, jsonb_set_lax(), allows null new values to either set the specified key to JSON null, delete the key, raise exception, or ignore the operation.
jsonb_set()
raise *an* exception
new null values?
IS 'return_target' CLEAR?
I haven't used these before, but following the examples, it seems to return the
"target" argument, unchanged.
| Add function min_scale() that returns the number of digits to the right the decimal point that is required to represent the numeric value with full precision (Pavel Stehule)
right *of*
that *are* required ?
|The old function names were kept for backward compatibility. DO WE HAVE NEW NAMES?
=> I think the docs are clear:
In releases of PostgreSQL before 13 there was no xid8 type, so variants of these functions were provided that used bigint to represent a 64-bit XID, with a correspondingly distinct snapshot data type txid_snapshot. These older functions have txid in their names. They are still supported for backward compatibility, but may be removed from a future release. See Table 9.76....
This improves performance for queries that access many object. The internal List API has also been improved.
many objects*
|Allow skipping of WAL for full table writes if wal_level is minimal (Kyotaro Horiguchi)
Allow WAL writes to be skipped...
And: this is not related to full_page_writes.
| Enable Unix-domain sockets support on Windows (Peter Eisentraut)
Enable support for ..
| Improve the performance when replaying DROP DATABASE commands when many tablespaces are in use (Fujii Masao)
s/the//
|Allow a sample of statements to be logged (Adrien Nayrat)
Allow logging a sample of statements
|Allow WAL receivers use a temporary replication slot if a permanent one is not specified (Peter Eisentraut, Sergei Kornilov)
*to* use
| Add leader_pid to pg_stat_activity to report parallel worker ownership (Julien Rouhaud)
s/ownership/leader/ ?
|Allow WAL recovery to continue even if invalid pages are referenced (Fujii Masao)
remove "WAL" or say:
Allow recovery to continue even if invalid pages are referenced by WAL (Fujii Masao)
A few things I have't fixed in my patch:
|Previously, this value was adjusted before effecting the number of concurrent requests. This value is now used directly. Conversion of old values to new ones can be done using:
|SELECT round(sum(OLD / n::float)) FROM generate_series(1, OLD) s(n);
I think the round() should be aliased, "AS new".
I think "before effecting" is confusing, maybe say:
| Previously, the effective value was computed internally from the user-supplied parameter...
|Allow partitioned tables to be logically replicated via publications (Amit Langote)
|Previously, partitions had to be replicated individually. Now partitioned tables can be published explicitly causing all partitions to be automatically published. Addition/removal of partitions from partitioned tables are automatically added/removed from publications. The CREATE PUBLICATION option publish_via_partition_root controls whether changes to partitions are published as their own or their ancestor's.
=> "causing any future partitions to be automatically published".
"addition/removal .. are automatically" isn't right
|Implement incremental sorting (James Coleman, Alexander Korotkov, Tomas Vondra)
|If a result is already sorted by several leading keys, this allows for batch sorting of additional trailing keys because the previous keys are already equal. This is controlled by enable_incremental_sort.
s/several/one or more/
remove "additional" ?
remove "batch" ?
maybe "of ONLY trailing keys"
|Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei Praliaskouski)
|This new behavior reduces the work necessary when the table needs to be frozen and allows pages to be set as all-visible. All-visible pages allow index-only scans to access fewer heap rows.
There's a lot of "allow" here, but it sounds like relaxing a restriction when
actually this is a new functionality. Maybe:
| Allow autovacuum to be triggered by INSERTs.
| ..and allows autovacuum to set pages as all-visible.
I already mentioned a couple things back in May that still stand out;:
|Add jsonpath .datetime() method (Nikita Glukhov, Teodor Sigaev, Oleg Bartunov, Alexander Korotkov)
|This allows json values to be converted to timestamps, which can then be processed in jsonpath expressions. This also adds jsonpath functions that support time zone-aware output.
timezone-aware or time-zone-aware, if you must.
Allow vacuum commands run by vacuumdb to operate in parallel mode (Masahiko Sawada)
=> I think this is still going to be lost/misunderstood/confuse some people.
vacuumdb already supports -j. This allows it to run vacuum(parallel N). So
maybe say "...to process indexes in parallel".
--
Justin
Attachments:
0001-fixes-release-notes.patchtext/x-diff; charset=us-asciiDownload
From 3f45433193d8fd3e2110df23e56a2ce31d232243 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sun, 6 Sep 2020 22:10:11 -0500
Subject: [PATCH] fixes release notes
---
doc/src/sgml/release-13.sgml | 38 +++++++++++++++++-------------------
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index e27b044408..f4cc65178a 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -731,8 +731,8 @@ Author: Noah Misch <noah@leadboat.com>
-->
<para>
- Allow skipping of <acronym>WAL</acronym> for <link
- linkend="guc-full-page-writes">full table writes</link> if <xref
+ Allow <acronym>WAL</acronym> writes to be skipped during a transaction
+ which creates or rewrites a relations if <xref
linkend="guc-wal-level"/> is <literal>minimal</literal> (Kyotaro
Horiguchi)
</para>
@@ -753,8 +753,8 @@ Author: Peter Eisentraut <peter@eisentraut.org>
-->
<para>
- Enable <link linkend="client-authentication">Unix-domain sockets</link>
- support on Windows (Peter Eisentraut)
+ Enable support for <link linkend="client-authentication">Unix-domain sockets</link>
+ on Windows (Peter Eisentraut)
</para>
</listitem>
@@ -765,7 +765,7 @@ Author: Fujii Masao <fujii@postgresql.org>
-->
<para>
- Improve the performance when replaying <link
+ Improve performance when replaying <link
linkend="sql-dropdatabase"><command>DROP DATABASE</command></link>
commands when many tablespaces are in use (Fujii Masao)
</para>
@@ -888,7 +888,7 @@ Author: Tomas Vondra <tomas.vondra@postgresql.org>
-->
<para>
- Allow a sample of statements to be logged (Adrien Nayrat)
+ Allow logging a sample of statements (Adrien Nayrat)
</para>
<para>
@@ -1000,7 +1000,7 @@ Author: Michael Paquier <michael@paquier.xyz>
<para>
Add <structfield>leader_pid</structfield> to <xref
- linkend="pg-stat-activity-view"/> to report parallel worker ownership
+ linkend="pg-stat-activity-view"/> to report parallel worker's leader process
(Julien Rouhaud)
</para>
</listitem>
@@ -1285,7 +1285,7 @@ Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
-->
<para>
- Allow <acronym>WAL</acronym> receivers use a temporary replication slot
+ Allow <acronym>WAL</acronym> receivers to use a temporary replication slot
if a permanent one is not specified (Peter Eisentraut, Sergei Kornilov)
</para>
@@ -1369,8 +1369,8 @@ Author: Fujii Masao <fujii@postgresql.org>
-->
<para>
- Allow <acronym>WAL</acronym> recovery to continue even if invalid
- pages are referenced (Fujii Masao)
+ Allow recovery to continue even if invalid
+ pages are referenced by <acronym>WAL</acronym> (Fujii Masao)
</para>
<para>
@@ -1689,15 +1689,14 @@ Author: Andrew Dunstan <andrew@dunslane.net>
<para>
Add alternate version of <link
- linkend="functions-json-processing-table"><function>jsonb_setI()</function></link>
+ linkend="functions-json-processing-table"><function>jsonb_set()</function></link>
with special <literal>NULL</literal> handling (Andrew Dunstan)
</para>
<para>
- The new function, <function>jsonb_set_lax()</function>, allows null
- new values to either set the specified key to <acronym>JSON</acronym>
- null, delete the key, raise exception, or ignore the operation.
- IS 'return_target' CLEAR?
+ The new function, <function>jsonb_set_lax()</function>, allows new
+ null values to either set the specified key to <acronym>JSON</acronym>
+ null, delete the key, raise an exception, or ignore the operation.
</para>
</listitem>
@@ -1863,8 +1862,8 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
<para>
Add function <link
linkend="functions-math-func-table"><function>min_scale()</function></link>
- that returns the number of digits to the right the decimal point
- that is required to represent the numeric value with full precision
+ that returns the number of digits to the right of the decimal point
+ that are required to represent the numeric value with full precision
(Pavel Stehule)
</para>
</listitem>
@@ -1913,8 +1912,7 @@ Author: Thomas Munro <tmunro@postgresql.org>
</para>
<para>
- The old function names were kept for backward compatibility. DO WE
- HAVE NEW NAMES?
+ The old functions were kept for backward compatibility.
</para>
</listitem>
@@ -2833,7 +2831,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
</para>
<para>
- This improves performance for queries that access many object.
+ This improves performance for queries that access many objects.
The internal List <acronym>API</acronym> has also been improved.
</para>
</listitem>
--
2.17.0
On Tue, May 12, 2020 at 10:28 AM Amit Langote <amitlangote09@gmail.com> wrote:
On Tue, May 12, 2020 at 8:51 AM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, May 8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
I have attached a patch with my suggestions above.
OK, I slightly modified the wording of your first change, patch
attached.Thanks. I checked that what you committed looks fine.
Sorry about not having reported this earlier, but I had noticed that
the wording of the partitioned tables logical replication item isn't
correct grammatically, which I noticed again while going through the
webpage. Attached fixes it as follows:
- to be automatically published. Addition/removal of partitions from
- partitioned tables are automatically added/removed from publications.
+ to be automatically published. Adding/removing partitions from
+ a partitioned table automatically adds/removes them from publications.--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
Attachments:
release-13-wording.patchapplication/octet-stream; name=release-13-wording.patchDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 68f9a0a..66425f0 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -383,8 +383,8 @@ Author: Peter Eisentraut <peter@eisentraut.org>
<para>
Previously, partitions had to be replicated individually. Now
partitioned tables can be published explicitly causing all partitions
- to be automatically published. Addition/removal of partitions from
- partitioned tables are automatically added/removed from publications.
+ to be automatically published. Adding/removing partitions from
+ a partitioned table automatically adds/removes then from publications.
The <link linkend="sql-createpublication"><command>CREATE
PUBLICATION</command></link> option
<literal>publish_via_partition_root</literal> controls whether changes
Hi,
On 5/4/20 11:16 PM, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Thank you again for compiling and maintaining the release notes through
another major release cycle, I know it's no small undertaking!
Attached is a proposal for the "major enhancements" section. I borrowed
from the press release[1]/messages/by-id/3bd579f8-438a-ed1a-ee20-738292099aae@postgresql.org but tried to stay true to the release notes
format and listed out the enhancements that way.
Open to suggestion, formatting changes, etc.
Thanks!
Jonathan
[1]: /messages/by-id/3bd579f8-438a-ed1a-ee20-738292099aae@postgresql.org
/messages/by-id/3bd579f8-438a-ed1a-ee20-738292099aae@postgresql.org
Attachments:
release-notes-13.patchtext/plain; charset=UTF-8; name=release-notes-13.patch; x-mac-creator=0; x-mac-type=0Download
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 68f9a0a9f1..95106921d7 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -6,29 +6,49 @@
<formalpara>
<title>Release date:</title>
- <para>2020-XX-XX, CURRENT AS OF 2020-08-09</para>
+ <para>2020-09-24, CURRENT AS OF 2020-09-09</para>
</formalpara>
<sect2>
<title>Overview</title>
<para>
- Major enhancements in <productname>PostgreSQL</productname> 13 include:
+ <productname>PostgreSQL</productname> 13 contains many new features and
+ enhancements, including:
</para>
- <!-- Items in this list summarize one or more items below -->
-
<itemizedlist>
-
<listitem>
- <para>TBD</para>
+ <para>
+ Space savings and performance gains from B-tree index deduplication
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Improved response times for queries that use aggregates or partitions
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Better query planning when using enhanced statistics
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Parallelized vacuuming of B-tree indexes
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Incremental sorting
+ </para>
</listitem>
-
</itemizedlist>
- <para>
- The above items are explained in more detail in the sections below.
- </para>
+ <para>
+ and more. The above items and other new features of PostgreSQL 13 are
+ explained in more detail in the sections below.
+ </para>
</sect2>
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
Attached is a proposal for the "major enhancements" section. I borrowed
from the press release[1] but tried to stay true to the release notes
format and listed out the enhancements that way.
Pushed with some very minor wording tweaks.
regards, tom lane
On 9/10/20 1:14 PM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
Attached is a proposal for the "major enhancements" section. I borrowed
from the press release[1] but tried to stay true to the release notes
format and listed out the enhancements that way.Pushed with some very minor wording tweaks.
Thanks! The tweaks were minor enough that it took a few readthroughs to
catch them.
One thing that did not make it through was this:
- <para>2020-XX-XX, CURRENT AS OF 2020-08-09</para>
+ <para>2020-09-24, CURRENT AS OF 2020-09-09</para>Is the plan to update that at a later date? Understandable if so, but
wanted to check.
Thanks,
Jonathan
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
One thing that did not make it through was this:
- <para>2020-XX-XX, CURRENT AS OF 2020-08-09</para> + <para>2020-09-24, CURRENT AS OF 2020-09-09</para>
Yeah, that's a placeholder to recall how far back to look for additional
changes to the relnotes, so unless you already read the git history that
far back and concluded nothing needed documenting, that was premature.
(I've just about finished making those updates and making an editorial
pass over the notes, so I will change it in a little bit.)
regards, tom lane
On Mon, Sep 07, 2020 at 08:40:26AM -0500, Justin Pryzby wrote:
Rebasing onto 3965de54e718600a4703233936e56a3202caf73f, I'm left with:
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 8fffc6fe0a..69d143e10c 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -131,7 +131,7 @@ Author: Thomas Munro <tmunro@postgresql.org>
</para> <programlisting>
-SELECT round(sum(<replaceable>OLDVALUE</replaceable> / n::float)) FROM generate_series(1, <replaceable>OLDVALUE</replaceable>) s(n);
+SELECT round(sum(<replaceable>OLDVALUE</replaceable> / n::float)) AS newvalue FROM generate_series(1, <replaceable>OLDVALUE</replaceable>) s(n);
</programlisting>
</listitem>@@ -776,8 +776,8 @@ Author: Noah Misch <noah@leadboat.com>
--> <para>
- Allow skipping of <acronym>WAL</acronym> for <link
- linkend="guc-full-page-writes">full table writes</link> if <xref
+ Allow <acronym>WAL</acronym> writes to be skipped during a transaction
+ which creates or rewrites a relation if <xref
linkend="guc-wal-level"/> is <literal>minimal</literal> (Kyotaro
Horiguchi)
</para>
@@ -1007,7 +1007,7 @@ Author: Michael Paquier <michael@paquier.xyz> <para>
Add <structfield>leader_pid</structfield> to <xref
- linkend="pg-stat-activity-view"/> to report parallel worker ownership
+ linkend="pg-stat-activity-view"/> to report parallel worker's leader process
(Julien Rouhaud)
</para>
</listitem>
@@ -1262,8 +1262,8 @@ Author: Peter Eisentraut <peter@eisentraut.org>
--> <para>
- Enable <link linkend="client-authentication">Unix-domain sockets</link>
- support on Windows (Peter Eisentraut)
+ Enable support for <link linkend="client-authentication">Unix-domain sockets</link>
+ on Windows (Peter Eisentraut)
</para>
</listitem>@@ -1391,8 +1391,8 @@ Author: Fujii Masao <fujii@postgresql.org>
--> <para>
- Allow <acronym>WAL</acronym> recovery to continue even if invalid
- pages are referenced (Fujii Masao)
+ Allow recovery to continue even if invalid
+ pages are referenced by <acronym>WAL</acronym> (Fujii Masao)
</para><para>
Justin Pryzby <pryzby@telsasoft.com> writes:
Rebasing onto 3965de54e718600a4703233936e56a3202caf73f, I'm left with:
Sorry, I hadn't seen that you submitted more updates. I pushed
these with minor additional wordsmithing.
regards, tom lane
On 2020-09-09 22:57, Jonathan S. Katz wrote:
+ <listitem> + <para> + Parallelized vacuuming of B-tree indexes + </para> + </listitem>
I don't think B-tree indexes are relevant here. AFAICT, this feature
applies to all indexes.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
On 2020-09-09 22:57, Jonathan S. Katz wrote:
+ <listitem> + <para> + Parallelized vacuuming of B-tree indexes + </para> + </listitem>I don't think B-tree indexes are relevant here. AFAICT, this feature
applies to all indexes.
Yes, parallel vacuum applies to all types of indexes provided by
PostgreSQL binary, and other types of indexes also can use it.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 9/15/20 5:22 AM, Masahiko Sawada wrote:
On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:On 2020-09-09 22:57, Jonathan S. Katz wrote:
+ <listitem> + <para> + Parallelized vacuuming of B-tree indexes + </para> + </listitem>I don't think B-tree indexes are relevant here. AFAICT, this feature
applies to all indexes.Yes, parallel vacuum applies to all types of indexes provided by
PostgreSQL binary, and other types of indexes also can use it.
I'm not sure where I got B-tree from. I've attached a correction.
Thanks,
Jonathan
Attachments:
vacuum-doc-fix.patchtext/plain; charset=UTF-8; name=vacuum-doc-fix.patch; x-mac-creator=0; x-mac-type=0Download
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 0ca970e452..f7852c8618 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -37,7 +37,7 @@
</listitem>
<listitem>
<para>
- Parallelized vacuuming of B-tree indexes
+ Parallelized vacuuming of indexes
</para>
</listitem>
<listitem>
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 5:22 AM, Masahiko Sawada wrote:
On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:I don't think B-tree indexes are relevant here. AFAICT, this feature
applies to all indexes.
I'm not sure where I got B-tree from. I've attached a correction.
Right, pushed. I clarified the main entry for this a tad, too.
regards, tom lane
On 9/15/20 9:49 AM, Jonathan S. Katz wrote:
On 9/15/20 5:22 AM, Masahiko Sawada wrote:
On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:On 2020-09-09 22:57, Jonathan S. Katz wrote:
+ <listitem> + <para> + Parallelized vacuuming of B-tree indexes + </para> + </listitem>I don't think B-tree indexes are relevant here. AFAICT, this feature
applies to all indexes.Yes, parallel vacuum applies to all types of indexes provided by
PostgreSQL binary, and other types of indexes also can use it.I'm not sure where I got B-tree from. I've attached a correction.
On a different note, I became aware of this[1]https://trac.osgeo.org/postgis/ticket/4753 and noticed that dropping
"CREATE EXTENSION ... FROM" was not listed in the incompatibilities
section, so proposing the attached. I have no strong opinions on the
final wording, mainly wanted to get it listed.
Thanks,
Jonathan
Attachments:
create-extension-from.patchtext/plain; charset=UTF-8; name=create-extension-from.patch; x-mac-creator=0; x-mac-type=0Download
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 0ca970e452..8fbaff4623 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -324,6 +324,19 @@ Author: Peter Geoghegan <pg@bowt.ie>
</para>
</listitem>
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2020-02-19 [70a773200] Remove support for upgrading extensions from "unpackaged
+-->
+
+ <para>
+ Remove support for <link linkend="sql-createextension"><command>CREATE
+ EXTENSION ... FROM</command></link>
+ (Tom Lane)
+ </para>
+ </listitem>
+
</itemizedlist>
</sect2>
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On a different note, I became aware of this[1] and noticed that dropping
"CREATE EXTENSION ... FROM" was not listed in the incompatibilities
section, so proposing the attached. I have no strong opinions on the
final wording, mainly wanted to get it listed.
It is listed already in the "Additional Modules" section (about line 2940
in release-13.sgml as of right now). I don't know Bruce's exact reasoning
for not including it in the "Incompatibilities" section, but I tend to
agree that it shouldn't be significant to any real-world user. I think
that the postgis testing issue you reference is just an ancient test
case that they should drop as no longer relevant.
regards, tom lane
On 9/15/20 11:45 AM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On a different note, I became aware of this[1] and noticed that dropping
"CREATE EXTENSION ... FROM" was not listed in the incompatibilities
section, so proposing the attached. I have no strong opinions on the
final wording, mainly wanted to get it listed.It is listed already in the "Additional Modules" section (about line 2940
in release-13.sgml as of right now).
...sort of. It talks about the feature, but does not talk about the
syntax removal, which is what I was originally searching for in the
release notes.
I don't know Bruce's exact reasoning
for not including it in the "Incompatibilities" section, but I tend to
agree that it shouldn't be significant to any real-world user.
I do tend agree with this intuitively but don't have any data to back it
up either way. That said, we did modify the command and it would be good
to at least mention the fact we dropped "FROM" somewhere in the release
notes. It provides a good reference in case someone reports an "issue"
in the future stemming from dropping the "FROM" keyword, we can say "oh
it changed in PG13, see XYZ."
(Speaking from having used the release notes to perform similar
troubleshooting).
I think
that the postgis testing issue you reference is just an ancient test
case that they should drop as no longer relevant.
Sure, and AIUI they're going to do that, mostly that was a reference
point to the changed syntax.
Jonathan
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 11:45 AM, Tom Lane wrote:
It is listed already in the "Additional Modules" section (about line 2940
in release-13.sgml as of right now).
...sort of. It talks about the feature, but does not talk about the
syntax removal, which is what I was originally searching for in the
release notes.
Ah. OK, we can certainly extend it to mention that. How about
(not bothering with markup yet)
Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
+
+The FROM option of CREATE EXTENSION is no longer supported.regards, tom lane
On 9/15/20 12:05 PM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 11:45 AM, Tom Lane wrote:
It is listed already in the "Additional Modules" section (about line 2940
in release-13.sgml as of right now)....sort of. It talks about the feature, but does not talk about the
syntax removal, which is what I was originally searching for in the
release notes.Ah. OK, we can certainly extend it to mention that. How about
(not bothering with markup yet)Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane) + +The FROM option of CREATE EXTENSION is no longer supported.
+1.
With that in place, I'm more ambivalent to whether or not it's mentioned
in the incompatibilities section as well, though would lean towards
having a mention of it there as it technically is one. But I don't feel
too strongly about it.
Jonathan
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 12:05 PM, Tom Lane wrote:
Ah. OK, we can certainly extend it to mention that. How about
(not bothering with markup yet)Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane) + +The FROM option of CREATE EXTENSION is no longer supported.
+1.
With that in place, I'm more ambivalent to whether or not it's mentioned
in the incompatibilities section as well, though would lean towards
having a mention of it there as it technically is one. But I don't feel
too strongly about it.
After thinking a bit, I'm inclined to agree that we should move it
to "Incompatibilities". It is a core server change (third-party
extensions don't have a choice to opt out, as per postgis' issue),
and even if it's trivial, we have some even-more-trivial issues
listed there, like command tag changes.
regards, tom lane
On 9/15/20 1:05 PM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 12:05 PM, Tom Lane wrote:
Ah. OK, we can certainly extend it to mention that. How about
(not bothering with markup yet)Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane) + +The FROM option of CREATE EXTENSION is no longer supported.+1.
With that in place, I'm more ambivalent to whether or not it's mentioned
in the incompatibilities section as well, though would lean towards
having a mention of it there as it technically is one. But I don't feel
too strongly about it.After thinking a bit, I'm inclined to agree that we should move it
to "Incompatibilities". It is a core server change (third-party
extensions don't have a choice to opt out, as per postgis' issue),
and even if it's trivial, we have some even-more-trivial issues
listed there, like command tag changes.
How about this?
Jonathan
Attachments:
create-extension-from-v2.patchtext/plain; charset=UTF-8; name=create-extension-from-v2.patch; x-mac-creator=0; x-mac-type=0Download
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 0ca970e452..bed56b0f3d 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -324,6 +324,19 @@ Author: Peter Geoghegan <pg@bowt.ie>
</para>
</listitem>
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2020-02-19 [70a773200] Remove support for upgrading extensions from "unpackaged
+-->
+
+ <para>
+ Remove support for <link linkend="sql-createextension"><command>CREATE
+ EXTENSION ... FROM</command></link>
+ (Tom Lane)
+ </para>
+ </listitem>
+
</itemizedlist>
</sect2>
@@ -2941,6 +2954,12 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
<para>
Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
</para>
+
+ <para>
+ The <literal>FROM</literal> option of
+ <link linkend="sql-createextension"><command>CREATE EXTENSION</command>
+ </link> is no longer supported.
+ </para>
</listitem>
<listitem>
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 1:05 PM, Tom Lane wrote:
After thinking a bit, I'm inclined to agree that we should move it
to "Incompatibilities". It is a core server change (third-party
extensions don't have a choice to opt out, as per postgis' issue),
and even if it's trivial, we have some even-more-trivial issues
listed there, like command tag changes.
How about this?
The other incompatibilities are only listed once, if they're minor.
I was just about to commit the attached.
regards, tom lane
Attachments:
doc-fix.patchtext/x-diff; charset=us-ascii; name=doc-fix.patchDownload
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 1f130ca1fe..3fd97c9d10 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -270,6 +270,25 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
</para>
</listitem>
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2020-02-19 [70a773200] Remove support for upgrading extensions from "unpackaged
+-->
+
+ <para>
+ Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
+ </para>
+
+ <para>
+ The <literal>FROM</literal> option
+ of <link linkend="sql-createextension"><command>CREATE
+ EXTENSION</command></link> is no longer supported. Any installations
+ still using unpackaged extensions should upgrade them to a packaged
+ version before updating to <productname>PostgreSQL</productname> 13.
+ </para>
+ </listitem>
+
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
@@ -2934,17 +2953,6 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
<listitem>
<!--
-Author: Tom Lane <tgl@sss.pgh.pa.us>
-2020-02-19 [70a773200] Remove support for upgrading extensions from "unpackaged
--->
-
- <para>
- Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
- </para>
- </listitem>
-
- <listitem>
-<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2019-12-20 [6136e94dc] Superuser can permit passwordless connections on postgre
-->
On 9/15/20 2:11 PM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 1:05 PM, Tom Lane wrote:
After thinking a bit, I'm inclined to agree that we should move it
to "Incompatibilities". It is a core server change (third-party
extensions don't have a choice to opt out, as per postgis' issue),
and even if it's trivial, we have some even-more-trivial issues
listed there, like command tag changes.How about this?
The other incompatibilities are only listed once, if they're minor.
I was just about to commit the attached.
Even better. +1
Jonathan
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 2:11 PM, Tom Lane wrote:
The other incompatibilities are only listed once, if they're minor.
I was just about to commit the attached.
Even better. +1
Pushed, thanks for looking.
regards, tom lane
On 9/15/20 2:30 PM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/15/20 2:11 PM, Tom Lane wrote:
The other incompatibilities are only listed once, if they're minor.
I was just about to commit the attached.Even better. +1
Pushed, thanks for looking.
Thanks for modifying...though I have a gripe about it being labeled a
gripe[1]https://git.postgresql.org/pg/commitdiff/d42c6176446440b185fcb95c214b7e40d5758b60 ;) Though it gave me a good laugh...
Jonathan
[1]: https://git.postgresql.org/pg/commitdiff/d42c6176446440b185fcb95c214b7e40d5758b60
https://git.postgresql.org/pg/commitdiff/d42c6176446440b185fcb95c214b7e40d5758b60
On Tue, Sep 15, 2020 at 11:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pushed, thanks for looking.
I think that the Postgres 13 release notes should mention the
enhancement to contrib/amcheck made by Alexander's commit d114cc53.
I suggest something along the lines of: "Make the cross-level
verification checks performed by contrib/amcheck's
bt_index_parent_check() function more robust".
--
Peter Geoghegan