First draft of back-branch release notes is done
See
https://git.postgresql.org/pg/commitdiff/082c9f5f761ced18a6f014f2638096f6a8228164
Please send comments/corrections before Sunday.
regards, tom lane
On 8/2/19 3:21 PM, Tom Lane wrote:
See
https://git.postgresql.org/pg/commitdiff/082c9f5f761ced18a6f014f2638096f6a8228164Please send comments/corrections before Sunday.
While working on the PR, I noticed this line:
"This fixes a regression introduced in June's minor releases..."
Perhaps instead of "June" it could be the specific version number (which
could cause some pain with the back branching?) or the "2019-06-20" release?
Thanks,
Jonathan
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
Perhaps instead of "June" it could be the specific version number (which
could cause some pain with the back branching?) or the "2019-06-20" release?
Putting in all the version numbers seems like a mess, but specifying
2019-06-20 would work --- or we could say "the most recent" minor
releases?
regards, tom lane
On 8/4/19 10:52 AM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
Perhaps instead of "June" it could be the specific version number (which
could cause some pain with the back branching?) or the "2019-06-20" release?Putting in all the version numbers seems like a mess, but specifying
2019-06-20 would work --- or we could say "the most recent" minor
releases?
That or "previous minor release" would seem to work.
(In the PR I'm putting in the versions it was introduced but we have the
luxury of only having one PR.)
Jonathan
On 8/4/19 11:08 AM, Jonathan S. Katz wrote:
On 8/4/19 10:52 AM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
Perhaps instead of "June" it could be the specific version number (which
could cause some pain with the back branching?) or the "2019-06-20" release?Putting in all the version numbers seems like a mess, but specifying
2019-06-20 would work --- or we could say "the most recent" minor
releases?That or "previous minor release" would seem to work.
(In the PR I'm putting in the versions it was introduced but we have the
luxury of only having one PR.)
Attached is the first draft of the PR.
Jonathan
Attachments:
I realize that this has now been sent, but I wanted to comment on one
item:
On 2019-Aug-04, Jonathan S. Katz wrote:
* Ensure that partition key columns will not be dropped as the result of an
"indirect drop," such as from a cascade from dropping the key column's data
type (e.g. a custom data type). This fix is applied only to newly created
partitioned tables: if you believe you have an affected partition table (e.g.
one where the partition key uses a custom data type), you will need to
create a new table and move your data into it.
Hmm, if I have this problem, I can pg_upgrade and the new database will
have correct dependencies, right? For some people, doing that might be
easier than creating and reloading large tables.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
On 2019-Aug-04, Jonathan S. Katz wrote:
* Ensure that partition key columns will not be dropped as the result of an
"indirect drop," such as from a cascade from dropping the key column's data
type (e.g. a custom data type). This fix is applied only to newly created
partitioned tables: if you believe you have an affected partition table (e.g.
one where the partition key uses a custom data type), you will need to
create a new table and move your data into it.
Hmm, if I have this problem, I can pg_upgrade and the new database will
have correct dependencies, right? For some people, doing that might be
easier than creating and reloading large tables.
Yeah, that should work.
regards, tom lane
On 8/8/19 2:15 PM, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
On 2019-Aug-04, Jonathan S. Katz wrote:
* Ensure that partition key columns will not be dropped as the result of an
"indirect drop," such as from a cascade from dropping the key column's data
type (e.g. a custom data type). This fix is applied only to newly created
partitioned tables: if you believe you have an affected partition table (e.g.
one where the partition key uses a custom data type), you will need to
create a new table and move your data into it.Hmm, if I have this problem, I can pg_upgrade and the new database will
have correct dependencies, right? For some people, doing that might be
easier than creating and reloading large tables.Yeah, that should work.
I modified the copy of the announcement on the website to include the
pg_upgrade option.
https://www.postgresql.org/about/news/1960/
Thanks!
Jonathan
On 2019-Aug-08, Jonathan S. Katz wrote:
I modified the copy of the announcement on the website to include the
pg_upgrade option.
Ooh, had I thought you were going to do that, I would have told you
about the item ending in a comma :-)
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 8/8/19 2:40 PM, Alvaro Herrera wrote:
On 2019-Aug-08, Jonathan S. Katz wrote:
I modified the copy of the announcement on the website to include the
pg_upgrade option.Ooh, had I thought you were going to do that, I would have told you
about the item ending in a comma :-)
:) I made a quick modification and opted for an "either" at the
beginning of that clause and a capitalized "OR" towards the end.
Jonathan
On 2019-Aug-08, Jonathan S. Katz wrote:
On 8/8/19 2:40 PM, Alvaro Herrera wrote:
On 2019-Aug-08, Jonathan S. Katz wrote:
I modified the copy of the announcement on the website to include the
pg_upgrade option.Ooh, had I thought you were going to do that, I would have told you
about the item ending in a comma :-):) I made a quick modification and opted for an "either" at the
beginning of that clause and a capitalized "OR" towards the end.
Oh, heh ... I was thinking of this line:
Fix for multi-column foreign keys when rebuilding a foreign key constraint,
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 8/8/19 2:45 PM, Alvaro Herrera wrote:
On 2019-Aug-08, Jonathan S. Katz wrote:
On 8/8/19 2:40 PM, Alvaro Herrera wrote:
On 2019-Aug-08, Jonathan S. Katz wrote:
I modified the copy of the announcement on the website to include the
pg_upgrade option.Ooh, had I thought you were going to do that, I would have told you
about the item ending in a comma :-):) I made a quick modification and opted for an "either" at the
beginning of that clause and a capitalized "OR" towards the end.Oh, heh ... I was thinking of this line:
Fix for multi-column foreign keys when rebuilding a foreign key constraint,
Oh oops. Fixed :) Thanks,
Jonathan