Re: First draft of back-branch release notes is done
Justin Pryzby writes: > It's of no concern, but I was curious why this one wasn't included: > commit 72aea955d49712a17c08748aa9abcbcf98c32fc5 > Author: Thomas Munro > Date: Fri Jan 6 16:38:46 2023 +1300 > Fix pg_truncate() on Windows. > Commit 57faaf376 added pg_truncate(const char *path, off_t length), but > "length" was ignored under WIN32 and the file was unconditionally > truncated to 0. > There was no live bug, since the only caller passes 0. I concluded that due to the lack of live bug, this would not be of interest to end users. The back-patch was just for future-proofing. regards, tom lane
Re: First draft of back-branch release notes is done
On Fri, Feb 03, 2023 at 02:32:39PM -0500, Tom Lane wrote: > ... at > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c > > As usual, please send corrections/comments by Sunday. It's of no concern, but I was curious why this one wasn't included: commit 72aea955d49712a17c08748aa9abcbcf98c32fc5 Author: Thomas Munro Date: Fri Jan 6 16:38:46 2023 +1300 Fix pg_truncate() on Windows. Commit 57faaf376 added pg_truncate(const char *path, off_t length), but "length" was ignored under WIN32 and the file was unconditionally truncated to 0. There was no live bug, since the only caller passes 0. Fix, and back-patch to 14 where the function arrived.
Re: First draft of back-branch release notes is done
On 2/5/23 9:39 PM, Tom Lane wrote: Prevent clobbering of cached parsetrees for utility statements in SQL functions (Tom Lane, Daniel Gustafsson) If a SQL-language function executes the same utility command more than once within a single calling query, it could crash or report strange errors such as unrecognized node type. regards, tom lane +1. Thanks! Jonathan OpenPGP_signature Description: OpenPGP digital signature
Re: First draft of back-branch release notes is done
"Jonathan S. Katz" writes: > On 2/5/23 3:01 PM, Tom Lane wrote: >> Fair. I was trying to avoid committing to specific consequences. >> The assertion failure seen in the original report (#17702) wouldn't >> occur for typical users, but they might see crashes or "unexpected node >> type" failures. Maybe we can say that instead. > I did a quick readthrough of #17702. Your proposal sounds reasonable. > Based on that explanation and reading #17702, I'm still not sure if this > will make the cut in the release announcement itself, but +1 for > modifying it in the release notes. The notes now say Prevent clobbering of cached parsetrees for utility statements in SQL functions (Tom Lane, Daniel Gustafsson) If a SQL-language function executes the same utility command more than once within a single calling query, it could crash or report strange errors such as unrecognized node type. regards, tom lane
Re: First draft of back-branch release notes is done
On 2/5/23 3:01 PM, Tom Lane wrote: "Jonathan S. Katz" writes: On Feb 4, 2023, at 10:24 AM, Tom Lane wrote: “Prevent clobbering of cached parsetrees…Bad things could happen if…” While I chuckled over the phrasing, I’m left to wonder what the “bad things” are, in case I need to check an older version to see if I’m susceptible to this bug. Fair. I was trying to avoid committing to specific consequences. The assertion failure seen in the original report (#17702) wouldn't occur for typical users, but they might see crashes or "unexpected node type" failures. Maybe we can say that instead. I did a quick readthrough of #17702. Your proposal sounds reasonable. Based on that explanation and reading #17702, I'm still not sure if this will make the cut in the release announcement itself, but +1 for modifying it in the release notes. Thanks, Jonathan OpenPGP_signature Description: OpenPGP digital signature
Re: First draft of back-branch release notes is done
Thomas Munro writes: > On Mon, Feb 6, 2023 at 8:57 AM Tom Lane wrote: >> Also, aren't shared tuplestores used in more places than just >> parallel hash join? I mentioned that as an example, not an >> exhaustive list of trouble spots. > Shared file sets (= a directory of temp files with automatic cleanup) > are used by more things, but shared tuplestores (= a shared file set > with a tuple-oriented interface on top, to support partial scan) are > currently only used by PHJ. Oh, okay. I'll change it to say "corruption within parallel hash join", then, and not use the word "tuplestore" at all. regards, tom lane
Re: First draft of back-branch release notes is done
On Mon, Feb 6, 2023 at 8:57 AM Tom Lane wrote: > Alvaro Herrera writes: > > On 2023-Feb-03, Tom Lane wrote: > >> Fix edge-case data corruption in shared tuplestores (Dmitry Astapov) > > > I think this sounds really scary, because people are going to think that > > their stored data can get corrupted -- they don't necessarily know what > > a "shared tuplestore" is. Maybe "Avoid query failures in parallel hash > > joins" as headline? > > Hmmm ... are we sure it *can't* lead to corruption of stored data, > if this happens during an INSERT or UPDATE plan? I'll grant that > such a case seems pretty unlikely though, as the bogus data > retrieved from the tuplestore would have to not cause a failure > within the query before it can get written out. Agreed. I think you have to be quite unlucky to hit this in the first place (very large tuples with very particular alignment), and then you'd be highly likely to fail in some way due to corrupted tuple size, making permanent corruption extremely unlikely. > Also, aren't shared tuplestores used in more places than just > parallel hash join? I mentioned that as an example, not an > exhaustive list of trouble spots. Shared file sets (= a directory of temp files with automatic cleanup) are used by more things, but shared tuplestores (= a shared file set with a tuple-oriented interface on top, to support partial scan) are currently only used by PHJ.
Re: First draft of back-branch release notes is done
I wrote: > Alvaro Herrera writes: >> I think this sounds really scary, because people are going to think that >> their stored data can get corrupted -- they don't necessarily know what >> a "shared tuplestore" is. Maybe "Avoid query failures in parallel hash >> joins" as headline? Maybe less scary if we make it clear we're talking about a temporary file? Fix edge-case corruption of temporary data within shared tuplestores (Dmitry Astapov) If the final chunk of a large tuple being written out to a temporary file was exactly 32760 bytes, it would be corrupted due to a fencepost bug. This is a hazard for parallelized plans that require a tuplestore, such as parallel hash join. The query would typically fail later with corrupted-data symptoms. regards, tom lane
Re: First draft of back-branch release notes is done
"Jonathan S. Katz" writes: > On Feb 4, 2023, at 10:24 AM, Tom Lane wrote: >> “Prevent clobbering of cached parsetrees…Bad things could happen if…” > While I chuckled over the phrasing, I’m left to wonder what the “bad things” > are, in case I > need to check an older version to see if I’m susceptible to this bug. Fair. I was trying to avoid committing to specific consequences. The assertion failure seen in the original report (#17702) wouldn't occur for typical users, but they might see crashes or "unexpected node type" failures. Maybe we can say that instead. regards, tom lane
Re: First draft of back-branch release notes is done
Alvaro Herrera writes: > On 2023-Feb-03, Tom Lane wrote: >> Fix edge-case data corruption in shared tuplestores (Dmitry Astapov) > I think this sounds really scary, because people are going to think that > their stored data can get corrupted -- they don't necessarily know what > a "shared tuplestore" is. Maybe "Avoid query failures in parallel hash > joins" as headline? Hmmm ... are we sure it *can't* lead to corruption of stored data, if this happens during an INSERT or UPDATE plan? I'll grant that such a case seems pretty unlikely though, as the bogus data retrieved from the tuplestore would have to not cause a failure within the query before it can get written out. Also, aren't shared tuplestores used in more places than just parallel hash join? I mentioned that as an example, not an exhaustive list of trouble spots. regards, tom lane
Re: First draft of back-branch release notes is done
On 2023-Feb-03, Tom Lane wrote: > ... at > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c > > As usual, please send corrections/comments by Sunday. Fix edge-case data corruption in shared tuplestores (Dmitry Astapov) If the final chunk of a large tuple being written out to disk was exactly 32760 bytes, it would be corrupted due to a fencepost bug. This is a hazard for parallelized plans that require a tuplestore, such as parallel hash join. The query would typically fail later with corrupted-data symptoms. I think this sounds really scary, because people are going to think that their stored data can get corrupted -- they don't necessarily know what a "shared tuplestore" is. Maybe "Avoid query failures in parallel hash joins" as headline? -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "The Gord often wonders why people threaten never to come back after they've been told never to return" (www.actsofgord.com)
Re: First draft of back-branch release notes is done
> On Feb 4, 2023, at 10:24 AM, Tom Lane wrote: > > ... at > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c > > As usual, please send corrections/comments by Sunday. While reviewing for the release announcement, I noticed this (abbreviated as I’m on my mobile): “Prevent clobbering of cached parsetrees…Bad things could happen if…” While I chuckled over the phrasing, I’m left to wonder what the “bad things” are, in case I need to check an older version to see if I’m susceptible to this bug. Thanks, Jonathan
Re: First draft of back-branch release notes is done
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 signature.asc Description: OpenPGP digital signature
Re: First draft of back-branch release notes is done
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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: First draft of back-branch release notes is done
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 signature.asc Description: OpenPGP digital signature
Re: First draft of back-branch release notes is done
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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: First draft of back-branch release notes is done
On 8/8/19 2:15 PM, Tom Lane wrote: > Alvaro Herrera 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 signature.asc Description: OpenPGP digital signature
Re: First draft of back-branch release notes is done
Alvaro Herrera 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
Re: First draft of back-branch release notes is done
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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: First draft of back-branch release notes is done
On 8/4/19 11:08 AM, Jonathan S. Katz wrote: > On 8/4/19 10:52 AM, Tom Lane wrote: >> "Jonathan S. Katz" 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 2019-08-08 Cumulative Update The PostgreSQL Global Development Group has released an update to all supported versions of our database system, including 11.5, 10.10, 9.6.15, 9.5.19, and 9.4.24, as well as the third beta of PostgreSQL 12. This release fixes over 40 bugs reported since the last release. Users should plan to apply this update at the next scheduled downtime. A Note on the PostgreSQL 12 Beta In the spirit of the open source PostgreSQL community, we strongly encourage you to test the new features of PostgreSQL 12 in your database systems to help us eliminate any bugs or other issues that may exist. While we do not advise you to run PostgreSQL 12 Beta 3 in your production environments, we encourage you to find ways to run your typical application workloads against this beta release. Your testing and feedback will help the community ensure that the PostgreSQL 12 release upholds our standards of providing a stable, reliable release of the world's most advanced open source relational database. Bug Fixes and Improvements -- This update also fixes over 40 bugs that were reported in the last several months. Some of these issues affect only version 11, but many affect all supported versions. Some of these fixes include: * Fix for `ALTER TABLE ... ALTER COLUMN TYPE` when multiple column types are modified in a single-command. This issue was introduced in the previous cumulative update (11.4, 10.9, 9.6.14, 9.5.18, 9.4.23, and 12 beta 2). * 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. * Prevent dropping a partitioned table's trigger if there are pending trigger events in child partitions. This particularly affects foreign key constraints, which are implemented by triggers. * Several additional fixes for partitioning, including a fix for partition pruning that could lead to inefficient queries. * Fix for parallel hash joins that could lead to duplicate result rows in `EXISTS` queries. * Several fixes for the query planner. * Several fixes for issues that would lead to query deadlocks. * Fix for multi-column foreign keys when rebuilding a foreign key constraint, * Prevent extended statistics from being built for inherited tables. * Fix for the canonicalization of date ranges that include `-infinity`/`infinity` endpoints to ensure the behavior matches the documentation. * Fix loss of fractional digits when converting very large `money` values to `numeric`. * Fix for PL/pgSQL functions that return composite types. * Make libpq ignore the `\r` carriage return in connection service files, which was causing connection failures in some edge cases. * Several fixes for `psql`, which includes avoiding incorrect tab completion options after `SET variable =`. * Improve reliability of `contrib/amcheck`'s index verification. * Set `initdb` to prefer the timezone behavior defined by the C library instead of what is defined by `localtime` or `posixrules`. This ensures PostgreSQL uses the "real" timezone name instead of an artificial name. * Fix `pg_dump` to ensure that custom operator classes are dumped in the correct order to prevent creating an unrestorable dump. * Fix possible lockup in `pgbench` when using -R option. * Fix spinlock assembly code for MIPS CPUs so that it works on MIPS r6. This update also contains tzdata release 2019b for DST law changes in Brazil, plus historical corrections for Hong Kong, Italy, and Palestine. This update also adds support for zic's new -b slim option to reduce the size of the installed zone files, though it is not currently being used by PostgreSQL. For more details, you can read the full copy of the release notes here: [https://www.postgresql.org/docs/release/](https://www.postgresql.org/docs/release/) Updating All PostgreSQL update releases are cumulative. As with other minor releases, users are not required to dump and reload their database or use `pg_upgrade` in order to
Re: First draft of back-branch release notes is done
On 8/4/19 10:52 AM, Tom Lane wrote: > "Jonathan S. Katz" 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 signature.asc Description: OpenPGP digital signature
Re: First draft of back-branch release notes is done
"Jonathan S. Katz" 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
Re: First draft of back-branch release notes is done
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 signature.asc Description: OpenPGP digital signature
