Thread: 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/082c9f5f761ced18a6f014f2638096f6a8228164 > > Please 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
Attachment
"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
Attachment
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
Attachment
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
Attachment
On 2019-Aug-08, Jonathan S. Katz wrote: > I modified the copy of the announcement on the website to include the > pg_upgrade option. > > https://www.postgresql.org/about/news/1960/ 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. >> >> https://www.postgresql.org/about/news/1960/ > > 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
Attachment
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. > >> > >> https://www.postgresql.org/about/news/1960/ > > > > 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. >>>> >>>> https://www.postgresql.org/about/news/1960/ >>> >>> 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