Обсуждение: 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"
--
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" > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=24e2885ee304cb6a94fdfc25a1a108344ed9f4f7 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).
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=
> 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.
no problem, thank you
Pavel
--
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" > > > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=24e2885ee304cb6a94fdfc25a1a108344ed9f4f7 > > 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
byenable_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 controlledby 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: https://www.postgresql.org/message-id/20200407223900.GT2228%40telsasoft.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 (AlexeyBashtanov, Á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 controlledby 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: > https://www.postgresql.org/message-id/20200407223900.GT2228%40telsasoft.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 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.
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 tables > > Uh, 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 tables > > > > Uh, 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 tables
> >
> > Uh, 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.
Вложения
> 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: > > https://momjian.us/pgsql_docs/release-13.html 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 +
Вложения
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: > > > > https://momjian.us/pgsql_docs/release-13.html > > 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/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. 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/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. 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 -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. 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: https://postgr.es/m/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/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. > > 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, AndreyBorodin) > > 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/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. > > 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 of > > What 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 of
> >
> > What 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: > > https://momjian.us/pgsql_docs/release-13.html 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
Вложения
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: https://postgr.es/m/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 tables >>> Uh, 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: > > https://momjian.us/pgsql_docs/release-13.html > 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. [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: > > > > https://momjian.us/pgsql_docs/release-13.html > > > > 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] ? ======================= 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] https://www.postgresql.org/message-id/20190813140127.GA4933%40alvherre.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_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? 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_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? > > 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 +
Вложения
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: > > > > https://momjian.us/pgsql_docs/release-13.html > > 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 +
Вложения
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 -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. 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: > > > > https://momjian.us/pgsql_docs/release-13.html > > > > 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 -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.
> ...
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 +
Вложения
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 -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. > > 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 -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.
> >
> > 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 -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. > > > > > > 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
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 the Shouldn'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 the > > Shouldn'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 the >> >> Shouldn'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
Вложения
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
Вложения
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
Вложения
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
Вложения
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
Вложения
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
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
Вложения
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] 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] https://www.postgresql.org/message-id/3bd579f8-438a-ed1a-ee20-738292099aae%40postgresql.org
Вложения
"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
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
Вложения
"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] 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 [1] https://trac.osgeo.org/postgis/ticket/4753
Вложения
"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
Вложения
"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
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] ;) Though it gave me a good laugh... Jonathan [1] 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