delta/postgresql.git/src/test, branch master git.postgresql.org: git/postgresql.git Reduce icu_validation_level default to WARNING. 2023-05-17T20:18:40+00:00 Jeff Davis jdavis@postgresql.org 2023-05-17T20:18:40+00:00 6de31ce446e59a1f947c7ebe4e4bbe7ca2b842bc Discussion: https://postgr.es/m/daa9f060aa2349ebc84444515efece49e7b32c5d.camel@j-davis.com 
Discussion: https://postgr.es/m/daa9f060aa2349ebc84444515efece49e7b32c5d.camel@j-davis.com
Add writeback to pg_stat_io 2023-05-17T18:18:35+00:00 Andres Freund andres@anarazel.de 2023-05-17T18:18:35+00:00 093e5c57d506783a95dd8feddd9a3f2651e1aeba 28e626bde00 added the concept of IOOps but neglected to include writeback operations. ac8d53dae5 added time spent doing these I/O operations. Without counting writeback, checkpointer write time in the log often differed substantially from that in pg_stat_io. To fix this, add IOOp IOOP_WRITEBACK and track writeback in pg_stat_io. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reported-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20230419172326.dhgyo4wrrhulovt6%40awork3.anarazel.de 
28e626bde00 added the concept of IOOps but neglected to include writeback
operations. ac8d53dae5 added time spent doing these I/O operations. Without
counting writeback, checkpointer write time in the log often differed
substantially from that in pg_stat_io. To fix this, add IOOp IOOP_WRITEBACK
and track writeback in pg_stat_io.

Bumps catversion.

Author: Melanie Plageman <melanieplageman@gmail.com>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reported-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20230419172326.dhgyo4wrrhulovt6%40awork3.anarazel.de
Use BUFFER_USAGE_LIMIT to reduce needed test table size 2023-05-17T18:17:41+00:00 Andres Freund andres@anarazel.de 2023-05-17T18:17:02+00:00 322875597c0c15cd85d03c8621038f4945c8caa3 Using the minimum BUFFER_USAGE_LIMIT value, we can make one of the pg_stat_io test tables smaller while still causing reuses. Author: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/CAAKRu_acc6iL4M3hvOTeztf_ZPpsB3Pqio5aVHgZ5q=Pi3BZKg@mail.gmail.com 
Using the minimum BUFFER_USAGE_LIMIT value, we can make one of the pg_stat_io
test tables smaller while still causing reuses.

Author: Melanie Plageman <melanieplageman@gmail.com>
Discussion: https://postgr.es/m/CAAKRu_acc6iL4M3hvOTeztf_ZPpsB3Pqio5aVHgZ5q=Pi3BZKg@mail.gmail.com
Revert "Add USER SET parameter values for pg_db_role_setting" 2023-05-17T17:28:57+00:00 Alexander Korotkov akorotkov@postgresql.org 2023-05-17T17:06:50+00:00 b9a7a822723aebb16cbe7e5fb874e5124745b07e This reverts commit 096dd80f3ccc and its fixups beecbe8e5001, afdd9f7f0e00, 529da086ba, db93e739ac61. Catversion is bumped. Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net 
This reverts commit 096dd80f3ccc and its fixups beecbe8e5001, afdd9f7f0e00,
529da086ba, db93e739ac61.

Catversion is bumped.

Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net
Fix some issues with improper placement of outer join clauses. 2023-05-17T15:14:04+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-05-17T15:13:52+00:00 9df8f903eb6758be5a19e66cdf77e922e9329c31 After applying outer-join identity 3 in the forward direction, it was possible for the planner to mistakenly apply a qual clause from above the two outer joins at the now-lower join level. This can give the wrong answer, since a value that would get nulled by the now-upper join might not yet be null. To fix, when we perform such a transformation, consider that the now-lower join hasn't really completed the outer join it's nominally responsible for and thus its relid set should not include that OJ's relid (nor should its output Vars have that nullingrel bit set). Instead we add those bits when the now-upper join is performed. The existing rules for qual placement then suffice to prevent higher qual clauses from dropping below the now-upper join. There are a few complications from needing to consider transitive closures in case multiple pushdowns have happened, but all in all it's not a very complex patch. This is all new logic (from 2489d76c4) so no need to back-patch. The added test cases all have the same results as in v15. Tom Lane and Richard Guo Discussion: https://postgr.es/m/0b819232-4b50-f245-1c7d-c8c61bf41827@postgrespro.ru 
After applying outer-join identity 3 in the forward direction,
it was possible for the planner to mistakenly apply a qual clause
from above the two outer joins at the now-lower join level.
This can give the wrong answer, since a value that would get nulled
by the now-upper join might not yet be null.

To fix, when we perform such a transformation, consider that the
now-lower join hasn't really completed the outer join it's nominally
responsible for and thus its relid set should not include that OJ's
relid (nor should its output Vars have that nullingrel bit set).
Instead we add those bits when the now-upper join is performed.
The existing rules for qual placement then suffice to prevent
higher qual clauses from dropping below the now-upper join.
There are a few complications from needing to consider transitive
closures in case multiple pushdowns have happened, but all in all
it's not a very complex patch.

This is all new logic (from 2489d76c4) so no need to back-patch.
The added test cases all have the same results as in v15.

Tom Lane and Richard Guo

Discussion: https://postgr.es/m/0b819232-4b50-f245-1c7d-c8c61bf41827@postgrespro.ru
Add back SQLValueFunction for SQL keywords 2023-05-17T01:19:17+00:00 Michael Paquier michael@paquier.xyz 2023-05-17T01:19:17+00:00 d8c3106bb60e4f87be595f241e173ba3c2b7aa2c This is equivalent to a revert of f193883 and fb32748, with the addition that the declaration of the SQLValueFunction node needs to gain a couple of node_attr for query jumbling. The performance impact of removing the function call inlining is proving to be too huge for some workloads where these are used. A worst-case test case of involving only simple SELECT queries with a SQL keyword is proving to lead to a reduction of 10% in TPS via pgbench and prepared queries on a high-end machine. None of the tests I ran back for this set of changes saw such a huge gap, but Alexander Lakhin and Andres Freund have found that this can be noticeable. Keeping the older performance would mean to do more inlining in the executor when using COERCE_SQL_SYNTAX for a function expression, similarly to what SQLValueFunction does. This requires more redesign work and there is little time until 16beta1 is released, so for now reverting the change is the best way forward, bringing back the previous performance. Bump catalog version. Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/b32bed1b-0746-9b20-1472-4bdc9ca66d52@gmail.com 
This is equivalent to a revert of f193883 and fb32748, with the addition
that the declaration of the SQLValueFunction node needs to gain a couple
of node_attr for query jumbling.  The performance impact of removing the
function call inlining is proving to be too huge for some workloads
where these are used.  A worst-case test case of involving only simple
SELECT queries with a SQL keyword is proving to lead to a reduction of
10% in TPS via pgbench and prepared queries on a high-end machine.

None of the tests I ran back for this set of changes saw such a huge
gap, but Alexander Lakhin and Andres Freund have found that this can be
noticeable.  Keeping the older performance would mean to do more
inlining in the executor when using COERCE_SQL_SYNTAX for a function
expression, similarly to what SQLValueFunction does.  This requires more
redesign work and there is little time until 16beta1 is released, so for
now reverting the change is the best way forward, bringing back the
previous performance.

Bump catalog version.

Reported-by: Alexander Lakhin
Discussion: https://postgr.es/m/b32bed1b-0746-9b20-1472-4bdc9ca66d52@gmail.com
Fix reported runtime for single tests in pg_regress 2023-05-16T08:49:48+00:00 Daniel Gustafsson dgustafsson@postgresql.org 2023-05-16T08:49:48+00:00 8cb94344c3c7130a0cd5e21e83705739f552187e Commit 558fff0adf got the order of the parameters to test_status_failed mixed up which resulted in the runtime being reported as 0 ms. Fix by changing the order to the correct one. No backpatching is needed since this has not been shipped in a release yet. Discussion: https://postgr.es/m/0134C9EC-5F6B-4EAC-B2D5-BB4249BEBD4D@yesql.se 
Commit 558fff0adf got the order of the parameters to test_status_failed
mixed up which resulted in the runtime being reported as 0 ms.  Fix by
changing the order to the correct one.  No backpatching is needed since
this has not been shipped in a release yet.

Discussion: https://postgr.es/m/0134C9EC-5F6B-4EAC-B2D5-BB4249BEBD4D@yesql.se
libpq: Error message improvement 2023-05-16T06:59:34+00:00 Peter Eisentraut peter@eisentraut.org 2023-05-16T06:59:34+00:00 c91f3560835f76bd8c9f614bebaa8c634b98b451 






psql: Adjust capitalization of table heading
2023-05-16T04:13:59+00:00

Peter Eisentraut
peter@eisentraut.org

2023-05-16T04:13:59+00:00

489b5409e4a0fa36c951561bae8ae4394e7d623f

for consistency with surrounding headings





for consistency with surrounding headings







Rename io_direct to debug_io_direct.
2023-05-14T22:31:14+00:00

Thomas Munro
tmunro@postgresql.org

2023-05-14T22:31:14+00:00

319bae9a8da66678d80d862440e54cebc7b1cc24

Give the new GUC introduced by d4e71df6 a name that is clearly not
intended for mainstream use quite yet.

Future proposals would drop the prefix only after adding infrastructure
to make it efficient.  Having the switch in the tree sooner is good
because it might lead to new discoveries about the hazards awaiting us
on a wide range of systems, but that name was too enticing and could
lead to cross-version confusion in future, per complaints from Noah and
Justin.

Suggested-by: Noah Misch <noah@leadboat.com>
Reviewed-by: Noah Misch <noah@leadboat.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (the idea, not the patch)
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (ditto)
Discussion: https://postgr.es/m/20230430041106.GA2268796%40rfd.leadboat.com





Give the new GUC introduced by d4e71df6 a name that is clearly not
intended for mainstream use quite yet.

Future proposals would drop the prefix only after adding infrastructure
to make it efficient.  Having the switch in the tree sooner is good
because it might lead to new discoveries about the hazards awaiting us
on a wide range of systems, but that name was too enticing and could
lead to cross-version confusion in future, per complaints from Noah and
Justin.

Suggested-by: Noah Misch <noah@leadboat.com>
Reviewed-by: Noah Misch <noah@leadboat.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (the idea, not the patch)
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (ditto)
Discussion: https://postgr.es/m/20230430041106.GA2268796%40rfd.leadboat.com