Re: pgsql: Disable run condition optimization for some WindowFuncs
> Thanks for pointing it out. There's not much I can do to correct the > commit message now. Never mind. Thanks for the fix. I am looking forward to seeing the fix for the master branch. Best reagards, -- Tatsuo Ishii SRA OSS LLC English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp
Re: pgsql: Disable run condition optimization for some WindowFuncs
David Rowley writes: > On Wed, 1 May 2024 at 17:02, Tatsuo Ishii wrote: >> Maybe you are talking about BUG #18305: > Thanks for pointing it out. There's not much I can do to correct the > commit message now. Yeah, once pushed commit messages are pretty much graven on stone tablets. But we do have a history of posting corrections in this mailing list, just in case future hackers want to track something down. regards, tom lane
Re: pgsql: Disable run condition optimization for some WindowFuncs
On Wed, 1 May 2024 at 17:02, Tatsuo Ishii wrote: > > Bug: #18170 > > Maybe you are talking about BUG #18305: > Unexpected error: "WindowFunc not found in subplan target lists" ? Unsure what happened there, but yes, you're right. That should be #18305 and [1]. I believe I just copied and pasted "Bug reference: 18305" from my emails to search the archives but trying that again, I don't see #18170 come up in the matches, so I dunno where #18170 came from. Thanks for pointing it out. There's not much I can do to correct the commit message now. David [1] https://www.postgresql.org/message-id/18305-33c49b4c830b3...@postgresql.org
pgsql: Fix typos and incorrect type in read_stream.c
Fix typos and incorrect type in read_stream.c max_ios should be int rather than int16, otherwise there's not much point in doing: max_ios = Min(max_ios, PG_INT16_MAX); Discussion: https://postgr.es/m/caaphdvr9un-xpdr_+afdogm38o2k8spfohimqz838ggutgy...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2ea4b29277222efe59dc25ed8385c8bcb1a3ed0f Modified Files -- src/backend/storage/aio/read_stream.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
Re: pgsql: Disable run condition optimization for some WindowFuncs
> Disable run condition optimization for some WindowFuncs > > 94985c210 added code to detect when WindowFuncs were monotonic and > allowed additional quals to be "pushed down" into the subquery to be > used as WindowClause runConditions in order to short-circuit execution > in nodeWindowAgg.c. > > The Node representation of runConditions wasn't well selected and > because we do qual pushdown before planning the subquery, the planning > of the subquery could perform subquery pull-up of nested subqueries. > For WindowFuncs with args, the arguments could be changed after pushing > the qual down to the subquery. > > This was made more difficult by the fact that the code duplicated the > WindowFunc inside an OpExpr to include in the WindowClauses runCondition > field. This could result in duplication of subqueries and a pull-up of > such a subquery could result in another initplan parameter being issued > for the 2nd version of the subplan. This could result in errors such as: > > ERROR: WindowFunc not found in subplan target lists > > Here in the backbranches, we don't have the flexibility to improve the > Node representation to resolve this, so instead we just disable the > runCondition optimization for ntile() unless the argument is a Const, > (v16 only) and likewise for count(expr) (both v15 and v16). count(*) is > unaffected. All other window functions which support this optimization > all take zero arguments and therefore are unaffected. > > Bug: #18170 Maybe you are talking about BUG #18305: Unexpected error: "WindowFunc not found in subplan target lists" ? > Reported-by: Zuming Jiang > Discussion: https://postgr.es/m/18170-f1d17bf9a0d58...@postgresql.org > Backpatch-through 15 (master will be fixed independently) > > Branch > -- > REL_16_STABLE > > Details > --- > https://git.postgresql.org/pg/commitdiff/9d36b883bfaaeee04f09101c5e7cde96906a256e > > Modified Files > -- > src/backend/utils/adt/int8.c | 15 ++ > src/backend/utils/adt/windowfuncs.c | 29 --- > src/test/regress/expected/window.out | 94 > src/test/regress/sql/window.sql | 43 ++--- > 4 files changed, 116 insertions(+), 65 deletions(-) >
pgsql: Disable run condition optimization for some WindowFuncs
Disable run condition optimization for some WindowFuncs 94985c210 added code to detect when WindowFuncs were monotonic and allowed additional quals to be "pushed down" into the subquery to be used as WindowClause runConditions in order to short-circuit execution in nodeWindowAgg.c. The Node representation of runConditions wasn't well selected and because we do qual pushdown before planning the subquery, the planning of the subquery could perform subquery pull-up of nested subqueries. For WindowFuncs with args, the arguments could be changed after pushing the qual down to the subquery. This was made more difficult by the fact that the code duplicated the WindowFunc inside an OpExpr to include in the WindowClauses runCondition field. This could result in duplication of subqueries and a pull-up of such a subquery could result in another initplan parameter being issued for the 2nd version of the subplan. This could result in errors such as: ERROR: WindowFunc not found in subplan target lists Here in the backbranches, we don't have the flexibility to improve the Node representation to resolve this, so instead we just disable the runCondition optimization for ntile() unless the argument is a Const, (v16 only) and likewise for count(expr) (both v15 and v16). count(*) is unaffected. All other window functions which support this optimization all take zero arguments and therefore are unaffected. Bug: #18170 Reported-by: Zuming Jiang Discussion: https://postgr.es/m/18170-f1d17bf9a0d58...@postgresql.org Backpatch-through 15 (master will be fixed independently) Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7e5d20bbd13fae7522003f7c3655c9165fb1b3e7 Modified Files -- src/backend/utils/adt/int8.c | 15 +++ src/backend/utils/adt/windowfuncs.c | 1 + src/test/regress/expected/window.out | 50 src/test/regress/sql/window.sql | 25 -- 4 files changed, 67 insertions(+), 24 deletions(-)
pgsql: Disable run condition optimization for some WindowFuncs
Disable run condition optimization for some WindowFuncs 94985c210 added code to detect when WindowFuncs were monotonic and allowed additional quals to be "pushed down" into the subquery to be used as WindowClause runConditions in order to short-circuit execution in nodeWindowAgg.c. The Node representation of runConditions wasn't well selected and because we do qual pushdown before planning the subquery, the planning of the subquery could perform subquery pull-up of nested subqueries. For WindowFuncs with args, the arguments could be changed after pushing the qual down to the subquery. This was made more difficult by the fact that the code duplicated the WindowFunc inside an OpExpr to include in the WindowClauses runCondition field. This could result in duplication of subqueries and a pull-up of such a subquery could result in another initplan parameter being issued for the 2nd version of the subplan. This could result in errors such as: ERROR: WindowFunc not found in subplan target lists Here in the backbranches, we don't have the flexibility to improve the Node representation to resolve this, so instead we just disable the runCondition optimization for ntile() unless the argument is a Const, (v16 only) and likewise for count(expr) (both v15 and v16). count(*) is unaffected. All other window functions which support this optimization all take zero arguments and therefore are unaffected. Bug: #18170 Reported-by: Zuming Jiang Discussion: https://postgr.es/m/18170-f1d17bf9a0d58...@postgresql.org Backpatch-through 15 (master will be fixed independently) Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9d36b883bfaaeee04f09101c5e7cde96906a256e Modified Files -- src/backend/utils/adt/int8.c | 15 ++ src/backend/utils/adt/windowfuncs.c | 29 --- src/test/regress/expected/window.out | 94 src/test/regress/sql/window.sql | 43 ++--- 4 files changed, 116 insertions(+), 65 deletions(-)
pgsql: Fix parallel vacuum buffer usage reporting.
Fix parallel vacuum buffer usage reporting.
A parallel worker's buffer usage is accumulated to its pgBufferUsage
and then is accumulated into the leader's one at the end of the
parallel vacuum. However, since the leader process used to use
dedicated VacuumPage{Hit, Miss, Dirty} globals for the buffer usage
reporting, the worker's buffer usage was not included, leading to an
incorrect buffer usage report.
To fix the problem, this commit makes vacuum use pgBufferUsage
instruments for buffer usage reporting instead of VacuumPage{Hit,
Miss, Dirty} globals. These global variables are still used by ANALYZE
command and autoanalyze.
This also fixes the buffer usage report of vacuuming on temporary
tables, since the buffers dirtied by MarkLocalBufferDirty() were not
tracked by the VacuumPageDirty variable.
Parallel vacuum was introduced in 13, but the buffer usage reporting
for VACUUM command with the VERBOSE option was implemented in
15. So backpatch to 15.
Reported-by: Anthonin Bonnefoy
Author: Anthonin Bonnefoy
Reviewed-by: Alena Rybakina, Masahiko Sawada
Discussion:
https://postgr.es/m/cao6_xqrqk+qzqcys_c6nk0cmfhuuwk85vt9crca1nfffbav...@mail.gmail.com
Backpatch-through: 15
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/5cd72cc0c5017a9d4de8b5d465a75946da5abd1d
Modified Files
--
src/backend/access/heap/vacuumlazy.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
pgsql: Fix parallel vacuum buffer usage reporting.
Fix parallel vacuum buffer usage reporting.
A parallel worker's buffer usage is accumulated to its pgBufferUsage
and then is accumulated into the leader's one at the end of the
parallel vacuum. However, since the leader process used to use
dedicated VacuumPage{Hit, Miss, Dirty} globals for the buffer usage
reporting, the worker's buffer usage was not included, leading to an
incorrect buffer usage report.
To fix the problem, this commit makes vacuum use pgBufferUsage
instruments for buffer usage reporting instead of VacuumPage{Hit,
Miss, Dirty} globals. These global variables are still used by ANALYZE
command and autoanalyze.
This also fixes the buffer usage report of vacuuming on temporary
tables, since the buffers dirtied by MarkLocalBufferDirty() were not
tracked by the VacuumPageDirty variable.
Parallel vacuum was introduced in 13, but the buffer usage reporting
for VACUUM command with the VERBOSE option was implemented in
15. So backpatch to 15.
Reported-by: Anthonin Bonnefoy
Author: Anthonin Bonnefoy
Reviewed-by: Alena Rybakina, Masahiko Sawada
Discussion:
https://postgr.es/m/cao6_xqrqk+qzqcys_c6nk0cmfhuuwk85vt9crca1nfffbav...@mail.gmail.com
Backpatch-through: 15
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/faba2f8f35df8cd07cd2205b0bb4815a10c38b14
Modified Files
--
src/backend/access/heap/vacuumlazy.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
pgsql: Fix parallel vacuum buffer usage reporting.
Fix parallel vacuum buffer usage reporting.
A parallel worker's buffer usage is accumulated to its pgBufferUsage
and then is accumulated into the leader's one at the end of the
parallel vacuum. However, since the leader process used to use
dedicated VacuumPage{Hit, Miss, Dirty} globals for the buffer usage
reporting, the worker's buffer usage was not included, leading to an
incorrect buffer usage report.
To fix the problem, this commit makes vacuum use pgBufferUsage
instruments for buffer usage reporting instead of VacuumPage{Hit,
Miss, Dirty} globals. These global variables are still used by ANALYZE
command and autoanalyze.
This also fixes the buffer usage report of vacuuming on temporary
tables, since the buffers dirtied by MarkLocalBufferDirty() were not
tracked by the VacuumPageDirty variable.
Parallel vacuum was introduced in 13, but the buffer usage reporting
for VACUUM command with the VERBOSE option was implemented in
15. So backpatch to 15.
Reported-by: Anthonin Bonnefoy
Author: Anthonin Bonnefoy
Reviewed-by: Alena Rybakina, Masahiko Sawada
Discussion:
https://postgr.es/m/cao6_xqrqk+qzqcys_c6nk0cmfhuuwk85vt9crca1nfffbav...@mail.gmail.com
Backpatch-through: 15
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f199436c12819d2c01b72eaa6429de0ca5838471
Modified Files
--
src/backend/access/heap/vacuumlazy.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
pgsql: Add tab completion for EXPLAIN (MEMORY|SERIALIZE)
Add tab completion for EXPLAIN (MEMORY|SERIALIZE) SERIALIZE has been added in 06286709ee06, and MEMORY in 5de890e3610d. Author: Jian He Discussion: https://postgr.es/m/cacjufxh5ubhbcg-omt7phomvnabf2x48jfefu24fexsqvgz...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2800fbb2b793fcb45d9d72ca60f7534722ebc4cd Modified Files -- src/bin/psql/tab-complete.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
Re: pgsql: Introduce "builtin" collation provider.
On Tue, 2024-04-23 at 11:23 +0200, Peter Eisentraut wrote: > I think I found a small bug in this commit. Good catch, thank you. Committed a fix. Regards, Jeff Davis
pgsql: Ensure we allocate NAMEDATALEN bytes for names in Index Only Sca
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans As an optimization, we store "name" columns as cstrings in btree indexes. Here we modify it so that Index Only Scans convert these cstrings back to names with NAMEDATALEN bytes rather than storing the cstring in the tuple slot, as was happening previously. Bug: #17855 Reported-by: Alexander Lakhin Reviewed-by: Alexander Lakhin, Tom Lane Discussion: https://postgr.es/m/17855-5f523e0f9769a...@postgresql.org Backpatch-through: 12, all supported versions Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e3f9dcabd6f2c4c1845f16ec24b59e0751b055af Modified Files -- src/backend/executor/nodeIndexonlyscan.c | 95 +-- src/include/catalog/pg_opclass.dat| 7 +- src/include/nodes/execnodes.h | 4 ++ src/test/regress/expected/index_including.out | 25 +++ src/test/regress/sql/index_including.sql | 19 ++ 5 files changed, 141 insertions(+), 9 deletions(-)
pgsql: Ensure we allocate NAMEDATALEN bytes for names in Index Only Sca
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans As an optimization, we store "name" columns as cstrings in btree indexes. Here we modify it so that Index Only Scans convert these cstrings back to names with NAMEDATALEN bytes rather than storing the cstring in the tuple slot, as was happening previously. Bug: #17855 Reported-by: Alexander Lakhin Reviewed-by: Alexander Lakhin, Tom Lane Discussion: https://postgr.es/m/17855-5f523e0f9769a...@postgresql.org Backpatch-through: 12, all supported versions Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0a34bcd0c23e7f67daad7b026320a12c52d797ac Modified Files -- src/backend/executor/nodeIndexonlyscan.c | 95 +-- src/include/catalog/pg_opclass.dat| 7 +- src/include/nodes/execnodes.h | 4 ++ src/test/regress/expected/index_including.out | 25 +++ src/test/regress/sql/index_including.sql | 19 ++ 5 files changed, 141 insertions(+), 9 deletions(-)
pgsql: Ensure we allocate NAMEDATALEN bytes for names in Index Only Sca
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans As an optimization, we store "name" columns as cstrings in btree indexes. Here we modify it so that Index Only Scans convert these cstrings back to names with NAMEDATALEN bytes rather than storing the cstring in the tuple slot, as was happening previously. Bug: #17855 Reported-by: Alexander Lakhin Reviewed-by: Alexander Lakhin, Tom Lane Discussion: https://postgr.es/m/17855-5f523e0f9769a...@postgresql.org Backpatch-through: 12, all supported versions Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e6b0efc65e5885a0e46050df341c88f4a5ee76cd Modified Files -- src/backend/executor/nodeIndexonlyscan.c | 95 +-- src/include/catalog/pg_opclass.dat| 7 +- src/include/nodes/execnodes.h | 4 ++ src/test/regress/expected/index_including.out | 25 +++ src/test/regress/sql/index_including.sql | 19 ++ 5 files changed, 141 insertions(+), 9 deletions(-)
pgsql: Ensure we allocate NAMEDATALEN bytes for names in Index Only Sca
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans As an optimization, we store "name" columns as cstrings in btree indexes. Here we modify it so that Index Only Scans convert these cstrings back to names with NAMEDATALEN bytes rather than storing the cstring in the tuple slot, as was happening previously. Bug: #17855 Reported-by: Alexander Lakhin Reviewed-by: Alexander Lakhin, Tom Lane Discussion: https://postgr.es/m/17855-5f523e0f9769a...@postgresql.org Backpatch-through: 12, all supported versions Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/52f21f928732418b333232a36fb02890f9c87b52 Modified Files -- src/backend/executor/nodeIndexonlyscan.c | 95 +-- src/include/catalog/pg_opclass.dat| 7 +- src/include/nodes/execnodes.h | 4 ++ src/test/regress/expected/index_including.out | 25 +++ src/test/regress/sql/index_including.sql | 19 ++ 5 files changed, 141 insertions(+), 9 deletions(-)
pgsql: Ensure we allocate NAMEDATALEN bytes for names in Index Only Sca
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans As an optimization, we store "name" columns as cstrings in btree indexes. Here we modify it so that Index Only Scans convert these cstrings back to names with NAMEDATALEN bytes rather than storing the cstring in the tuple slot, as was happening previously. Bug: #17855 Reported-by: Alexander Lakhin Reviewed-by: Alexander Lakhin, Tom Lane Discussion: https://postgr.es/m/17855-5f523e0f9769a...@postgresql.org Backpatch-through: 12, all supported versions Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/68d358545037c51723a7ff0ab96f489e066a6fdd Modified Files -- src/backend/executor/nodeIndexonlyscan.c | 95 +-- src/include/catalog/pg_opclass.dat| 7 +- src/include/nodes/execnodes.h | 4 ++ src/test/regress/expected/index_including.out | 25 +++ src/test/regress/sql/index_including.sql | 19 ++ 5 files changed, 141 insertions(+), 9 deletions(-)
pgsql: Ensure we allocate NAMEDATALEN bytes for names in Index Only Sca
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans As an optimization, we store "name" columns as cstrings in btree indexes. Here we modify it so that Index Only Scans convert these cstrings back to names with NAMEDATALEN bytes rather than storing the cstring in the tuple slot, as was happening previously. Bug: #17855 Reported-by: Alexander Lakhin Reviewed-by: Alexander Lakhin, Tom Lane Discussion: https://postgr.es/m/17855-5f523e0f9769a...@postgresql.org Backpatch-through: 12, all supported versions Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a63224be49b86fccbf1bf1809d516626bce7ba11 Modified Files -- src/backend/executor/nodeIndexonlyscan.c | 95 +-- src/include/catalog/pg_opclass.dat| 7 +- src/include/nodes/execnodes.h | 4 ++ src/test/regress/expected/index_including.out | 25 +++ src/test/regress/sql/index_including.sql | 19 ++ 5 files changed, 141 insertions(+), 9 deletions(-)
pgsql: Fix locale options checking in CREATE DATABASE.
Fix locale options checking in CREATE DATABASE. Discussion: https://postgr.es/m/4ea13583-7305-40b0-8525-58381533e...@eisentraut.org Reported-by: Peter Eisentraut Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7562a9bd7100702ce7878a17f4aaac1df08a8e09 Modified Files -- src/backend/commands/dbcommands.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Disallow converting a table to a view within an outer SQL comman
Disallow converting a table to a view within an outer SQL command. We have long disallowed all forms of ALTER TABLE if the table is already opened by some outer SQL command in the same session. This has the same purpose as obtaining AccessExclusiveLock, but since a session's own locks don't conflict the lock only blocks use of the table by other sessions, not our own. Without this check, the ALTER might confuse the outer SQL command since any previous inspection of the table would potentially become invalid. However, the RelisBecomingView code path in DefineQueryRewrite never got that memo, and assumed that AccessExclusiveLock is sufficient for performing something morally equivalent to a rather invasive ALTER TABLE. Unsurprisingly, this can confuse an outer command that is trying to do something with the table. This was submitted as a security issue, but the security team has been unable to identify any consequence worse than a null pointer dereference (from trying to access rd_tableam methods that the relation no longer has). Therefore, in accordance with our usual policy, it's not security material and should just be fixed as a routine bug. Fix by disallowing the operation if the table is open locally, exactly as ALTER TABLE does it. Per an anonymous security researcher, via Bundesamt für Sicherheit in der Informationstechnik. Patch v12-v15 only. In v16 and later, we removed this code altogether (cf. commit b23cd185f), so that there's no issue. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1ee22d1e87b3c442928abe9535d6b2bf8460fc67 Modified Files -- src/backend/rewrite/rewriteDefine.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Disallow converting a table to a view within an outer SQL comman
Disallow converting a table to a view within an outer SQL command. We have long disallowed all forms of ALTER TABLE if the table is already opened by some outer SQL command in the same session. This has the same purpose as obtaining AccessExclusiveLock, but since a session's own locks don't conflict the lock only blocks use of the table by other sessions, not our own. Without this check, the ALTER might confuse the outer SQL command since any previous inspection of the table would potentially become invalid. However, the RelisBecomingView code path in DefineQueryRewrite never got that memo, and assumed that AccessExclusiveLock is sufficient for performing something morally equivalent to a rather invasive ALTER TABLE. Unsurprisingly, this can confuse an outer command that is trying to do something with the table. This was submitted as a security issue, but the security team has been unable to identify any consequence worse than a null pointer dereference (from trying to access rd_tableam methods that the relation no longer has). Therefore, in accordance with our usual policy, it's not security material and should just be fixed as a routine bug. Fix by disallowing the operation if the table is open locally, exactly as ALTER TABLE does it. Per an anonymous security researcher, via Bundesamt für Sicherheit in der Informationstechnik. Patch v12-v15 only. In v16 and later, we removed this code altogether (cf. commit b23cd185f), so that there's no issue. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf379b555c06034bcd1be384cc145d8264213f41 Modified Files -- src/backend/rewrite/rewriteDefine.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Disallow converting a table to a view within an outer SQL comman
Disallow converting a table to a view within an outer SQL command. We have long disallowed all forms of ALTER TABLE if the table is already opened by some outer SQL command in the same session. This has the same purpose as obtaining AccessExclusiveLock, but since a session's own locks don't conflict the lock only blocks use of the table by other sessions, not our own. Without this check, the ALTER might confuse the outer SQL command since any previous inspection of the table would potentially become invalid. However, the RelisBecomingView code path in DefineQueryRewrite never got that memo, and assumed that AccessExclusiveLock is sufficient for performing something morally equivalent to a rather invasive ALTER TABLE. Unsurprisingly, this can confuse an outer command that is trying to do something with the table. This was submitted as a security issue, but the security team has been unable to identify any consequence worse than a null pointer dereference (from trying to access rd_tableam methods that the relation no longer has). Therefore, in accordance with our usual policy, it's not security material and should just be fixed as a routine bug. Fix by disallowing the operation if the table is open locally, exactly as ALTER TABLE does it. Per an anonymous security researcher, via Bundesamt für Sicherheit in der Informationstechnik. Patch v12-v15 only. In v16 and later, we removed this code altogether (cf. commit b23cd185f), so that there's no issue. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/56d30fb10d5ce5e2d8b432eeaca8ecf2fc2a6900 Modified Files -- src/backend/rewrite/rewriteDefine.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Disallow converting a table to a view within an outer SQL comman
Disallow converting a table to a view within an outer SQL command. We have long disallowed all forms of ALTER TABLE if the table is already opened by some outer SQL command in the same session. This has the same purpose as obtaining AccessExclusiveLock, but since a session's own locks don't conflict the lock only blocks use of the table by other sessions, not our own. Without this check, the ALTER might confuse the outer SQL command since any previous inspection of the table would potentially become invalid. However, the RelisBecomingView code path in DefineQueryRewrite never got that memo, and assumed that AccessExclusiveLock is sufficient for performing something morally equivalent to a rather invasive ALTER TABLE. Unsurprisingly, this can confuse an outer command that is trying to do something with the table. This was submitted as a security issue, but the security team has been unable to identify any consequence worse than a null pointer dereference (from trying to access rd_tableam methods that the relation no longer has). Therefore, in accordance with our usual policy, it's not security material and should just be fixed as a routine bug. Fix by disallowing the operation if the table is open locally, exactly as ALTER TABLE does it. Per an anonymous security researcher, via Bundesamt für Sicherheit in der Informationstechnik. Patch v12-v15 only. In v16 and later, we removed this code altogether (cf. commit b23cd185f), so that there's no issue. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/51189f98a9fc88a63ae6a9635da8adb427f9958c Modified Files -- src/backend/rewrite/rewriteDefine.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Fix one more portability shortcoming in new test_pg_dump test.
Fix one more portability shortcoming in new test_pg_dump test. If the bootstrap superuser's name requires quoting, regroleout will supply double quotes ... but the result of CURRENT_USER is just the literal name. Apply quote_ident() to ensure a match. Per Andrew Dunstan's off-list investigation of buildfarm member prion's failures. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d12b4ba1bd3eedd862064cf1dad5ff107c5cba90 Modified Files -- src/test/modules/test_pg_dump/expected/test_pg_dump.out | 8 src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 8 2 files changed, 8 insertions(+), 8 deletions(-)
pgsql: doc: Remove one example related to pg_input_error_info()
doc: Remove one example related to pg_input_error_info() This slightly bloated the contents of the function table for this entry, without really bringing extra value. Per discussion with Jian He and David G. Johnston. Discussion: https://postgr.es/m/CACJufxGdyoBJQMSxwdxNK=k8m5wuth5fdfd4wq_k4f7+1j2...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f6ab942f5de003f37b88580154ebb614655d7e11 Modified Files -- doc/src/sgml/func.sgml | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-)
pgsql: Stabilize regression tests introduced by 259c96fa8f
Stabilize regression tests introduced by 259c96fa8f Add the ORDER BY clause to new queries to avoid ordering ambiguity. Per buildfarm member rorqual. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/449cdcd486bfc6864e4fa6784cc1526a94fe69db Modified Files -- src/test/regress/expected/partition_merge.out | 5 +++-- src/test/regress/expected/partition_split.out | 3 ++- src/test/regress/sql/partition_merge.sql | 3 ++- src/test/regress/sql/partition_split.sql | 3 ++- 4 files changed, 9 insertions(+), 5 deletions(-)
pgsql: Inherit parent's AM for partition MERGE/SPLIT operations
Inherit parent's AM for partition MERGE/SPLIT operations This commit makes new partitions created by ALTER TABLE ... SPLIT PARTITION and ALTER TABLE ... MERGE PARTITIONS commands inherit the paret table access method. Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/84ada05b-be5c-473e-6d1c-ebe5dd21b190%40gmail.com Reviewed-by: Pavel Borisov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/259c96fa8f78c0446eba1880850ea6fbe5092120 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 2 ++ src/backend/commands/tablecmds.c | 6 ++ src/test/regress/expected/partition_merge.out | 18 ++ src/test/regress/expected/partition_split.out | 23 +-- src/test/regress/sql/partition_merge.sql | 13 + src/test/regress/sql/partition_split.sql | 14 ++ 6 files changed, 74 insertions(+), 2 deletions(-)
pgsql: Change the way ATExecMergePartitions() handles the name collisio
Change the way ATExecMergePartitions() handles the name collision The name collision happens when the name of the new partition is the same as the name of one of the merging partitions. Currently, ATExecMergePartitions() first gives the new partition a temporary name and then renames it when old partitions are deleted. That negatively influences the naming of related objects like indexes and constrains, which could inherit a temporary name. This commit changes the implementation in the following way. A merging partition gets renamed first, then the new partition is created with the right name immediately. This resolves the issue of the naming of related objects. Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/edfbd846-dcc1-42d1-ac26-715691b687d3%40postgrespro.ru Author: Dmitry Koval, Alexander Korotkov Reviewed-by: Robert Haas, Justin Pryzby, Pavel Borisov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/885742b9f88b9386368ee94df8c94d154677ffba Modified Files -- src/backend/commands/tablecmds.c | 63 +-- src/test/regress/expected/partition_merge.out | 25 +++ src/test/regress/sql/partition_merge.sql | 18 3 files changed, 73 insertions(+), 33 deletions(-)
pgsql: Add tab completion for partition MERGE/SPLIT operations
Add tab completion for partition MERGE/SPLIT operations This commit implements psql tab completion for ALTER TABLE ... SPLIT PARTITION and ALTER TABLE ... MERGE PARTITIONS commands. Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/5dee3937-8e9f-cca4-11fb-737709a92b37%40gmail.com Author: Dagfinn Ilmari Mannsåker, Pavel Borisov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/60ae37a8bc02f7a4beef442ee7b4656fba0e4e71 Modified Files -- src/bin/psql/tab-complete.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-)
pgsql: Document the way partition MERGE/SPLIT operations create new par
Document the way partition MERGE/SPLIT operations create new partitions Reported-by: Justin Pryzby Discussion: https://postgr.es/m/ZilrByTp-pbz6Mvf%40pryzbyj2023 Reviewed-by: Justin Pryzby Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/842c9b27057e8ecea02b816e3ec6c208779b3d39 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 12 1 file changed, 12 insertions(+)
pgsql: Rename tables in tests of partition MERGE/SPLIT operations
Rename tables in tests of partition MERGE/SPLIT operations Replace "salesman" with "salesperson", "salesmen" with "salespeople". The names are both gramatically correct and gender-neutral. Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/fdaa003e-919c-cbc9-4f0c-e4546e96bd65%40gmail.com Reviewed-by: Robert Haas, Pavel Borisov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f4fc7cb54b6a9041f7064de71cb3ee3c4f48e061 Modified Files -- src/test/regress/expected/partition_merge.out | 666 ++--- src/test/regress/expected/partition_split.out | 1266 - src/test/regress/sql/partition_merge.sql | 160 ++-- src/test/regress/sql/partition_split.sql | 280 +++--- 4 files changed, 1186 insertions(+), 1186 deletions(-)
pgsql: Fix error message in check_partition_bounds_for_split_range()
Fix error message in check_partition_bounds_for_split_range() Currently, the error message is produced by a system of complex substitutions making it quite untranslatable and hard to read. This commit splits this into 4 plain error messages suitable for translation. Reported-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20240408.152402.1485994009160660141.horikyota.ntt%40gmail.com Reviewed-by: Pavel Borisov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/96c7381c4ceee2ef7c0a7327beb71dec47cf855e Modified Files -- src/backend/partitioning/partbounds.c | 70 --- 1 file changed, 49 insertions(+), 21 deletions(-)
pgsql: Make new partitions with parent's persistence during MERGE/SPLIT
Make new partitions with parent's persistence during MERGE/SPLIT The createPartitionTable() function is responsible for creating new partitions for ALTER TABLE ... MERGE PARTITIONS, and ALTER TABLE ... SPLIT PARTITION commands. It emulates the behaviour of CREATE TABLE ... (LIKE ...), where new table persistence should be specified by the user. In the table partitioning persistent of the partition and its parent must match. So, this commit makes createPartitionTable() copy the persistence of the parent partition. Also, this commit makes createPartitionTable() recheck the persistence after the new table creation. This is needed because persistence might be affected by pg_temp in search_path. This commit also changes the signature of createPartitionTable() making it take the parent's Relation itself instead of the name of the parent relation, and return the Relation of new partition. That doesn't lead to complications, because both callers have the parent table open and need to open the new partition. Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/dbc8b96c-3cf0-d1ee-860d-0e491da20485%40gmail.com Author: Dmitry Koval Reviewed-by: Alexander Korotkov, Robert Haas, Justin Pryzby, Pavel Borisov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fcf80c5d5f0f3787e70fca8fd029d2e08a923f91 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 6 ++ src/backend/commands/tablecmds.c | 75 +- src/test/regress/expected/partition_merge.out | 134 ++ src/test/regress/expected/partition_split.out | 75 +- src/test/regress/sql/partition_merge.sql | 88 +++-- src/test/regress/sql/partition_split.sql | 43 - 6 files changed, 364 insertions(+), 57 deletions(-)
