pgsql: Stop creating constraints during DETACH CONCURRENTLY
Stop creating constraints during DETACH CONCURRENTLY Commit 71f4c8c6f74b (which implemented DETACH CONCURRENTLY) added code to create a separate table constraint when a table is detached concurrently, identical to the partition constraint, on the theory that such a constraint was needed in case the optimizer had constructed any query plans that depended on the constraint being there. However, that theory was apparently bogus because any such plans would be invalidated. For hash partitioning, those constraints are problematic, because their expressions reference the OID of the parent partitioned table, to which the detached table is no longer related; this causes all sorts of problems (such as inability of restoring a pg_dump of that table, and the table no longer working properly if the partitioned table is later dropped). We'd like to get rid of all those constraints. In fact, for branch master, do that -- no longer create any substitute constraints. However, out of fear that some users might somehow depend on these constraints for other partitioning strategies, for stable branches (back to 14, which added DETACH CONCURRENTLY), only do it for hash partitioning. (If you repeatedly DETACH CONCURRENTLY and then ATTACH a partition, then with this constraint addition you don't need to scan the table in the ATTACH step, which presumably is good. But if users really valued this feature, they would have requested that it worked for non-concurrent DETACH also.) Author: Haiyang Li Reported-by: Fei Changhong Reported-by: Haiyang Li Backpatch-through: 14 Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/08c037dff96103f607d30c487d11d3bf43a531ea Modified Files -- src/backend/commands/tablecmds.c | 14 +- src/test/regress/expected/alter_table.out | 8 src/test/regress/sql/alter_table.sql | 9 + 3 files changed, 26 insertions(+), 5 deletions(-)
pgsql: Stop creating constraints during DETACH CONCURRENTLY
Stop creating constraints during DETACH CONCURRENTLY Commit 71f4c8c6f74b (which implemented DETACH CONCURRENTLY) added code to create a separate table constraint when a table is detached concurrently, identical to the partition constraint, on the theory that such a constraint was needed in case the optimizer had constructed any query plans that depended on the constraint being there. However, that theory was apparently bogus because any such plans would be invalidated. For hash partitioning, those constraints are problematic, because their expressions reference the OID of the parent partitioned table, to which the detached table is no longer related; this causes all sorts of problems (such as inability of restoring a pg_dump of that table, and the table no longer working properly if the partitioned table is later dropped). We'd like to get rid of all those constraints. In fact, for branch master, do that -- no longer create any substitute constraints. However, out of fear that some users might somehow depend on these constraints for other partitioning strategies, for stable branches (back to 14, which added DETACH CONCURRENTLY), only do it for hash partitioning. (If you repeatedly DETACH CONCURRENTLY and then ATTACH a partition, then with this constraint addition you don't need to scan the table in the ATTACH step, which presumably is good. But if users really valued this feature, they would have requested that it worked for non-concurrent DETACH also.) Author: Haiyang Li Reported-by: Fei Changhong Reported-by: Haiyang Li Backpatch-through: 14 Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b835759ec7e8357c341f051df91168c04f032025 Modified Files -- src/backend/commands/tablecmds.c | 14 +- src/test/regress/expected/alter_table.out | 8 src/test/regress/sql/alter_table.sql | 9 + 3 files changed, 26 insertions(+), 5 deletions(-)
pgsql: Eliminate COPY FREEZE use of XLOG_HEAP2_VISIBLE
Eliminate COPY FREEZE use of XLOG_HEAP2_VISIBLE Instead of emitting a separate WAL XLOG_HEAP2_VISIBLE record for setting bits in the VM, specify the VM block changes in the XLOG_HEAP2_MULTI_INSERT record. This halves the number of WAL records emitted by COPY FREEZE. Author: Melanie Plageman Reviewed-by: Andres Freund Reviewed-by: Robert Haas Reviewed-by: Kirill Reshke Discussion: https://postgr.es/m/flat/CAAKRu_ZMw6Npd_qm2KM%2BFwQ3cMOMx1Dh3VMhp8-V7SOLxdK9-g%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d96f87332b3786abd23cba47459546799c562b8c Modified Files -- src/backend/access/heap/heapam.c| 43 src/backend/access/heap/heapam_xlog.c | 49 ++- src/backend/access/heap/visibilitymap.c | 70 - src/backend/access/rmgrdesc/heapdesc.c | 6 +++ src/include/access/visibilitymap.h | 4 ++ 5 files changed, 154 insertions(+), 18 deletions(-)
pgsql: dbase_redo: Fix Valgrind-reported memory leak
dbase_redo: Fix Valgrind-reported memory leak Introduced by my (Álvaro's) commit 9e4f914b5eba, which was itself backpatched to pg10, though only pg15 and up contain the problem because of commit 9c08aea6a309. This isn't a particularly significant leak, but given the fix is trivial, we might as well backpatch to all branches where it applies, so do that. Author: Nathan Bossart Reported-by: Andres Freund Discussion: https://postgr.es/m/x4odfdlrwvsjawscnqsqjpofvauxslw7b4oyvxgt5owoyf4ysn@heafjusodrz7 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/23b316c36ab4a0cc2522fd09cb964809aa313e0b Modified Files -- src/backend/commands/dbcommands.c | 1 + 1 file changed, 1 insertion(+)
pgsql: dbase_redo: Fix Valgrind-reported memory leak
dbase_redo: Fix Valgrind-reported memory leak Introduced by my (Álvaro's) commit 9e4f914b5eba, which was itself backpatched to pg10, though only pg15 and up contain the problem because of commit 9c08aea6a309. This isn't a particularly significant leak, but given the fix is trivial, we might as well backpatch to all branches where it applies, so do that. Author: Nathan Bossart Reported-by: Andres Freund Discussion: https://postgr.es/m/x4odfdlrwvsjawscnqsqjpofvauxslw7b4oyvxgt5owoyf4ysn@heafjusodrz7 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c72b5c536032d636cf35d964c216c3e44e2b1efe Modified Files -- src/backend/commands/dbcommands.c | 1 + 1 file changed, 1 insertion(+)
pgsql: dbase_redo: Fix Valgrind-reported memory leak
dbase_redo: Fix Valgrind-reported memory leak Introduced by my (Álvaro's) commit 9e4f914b5eba, which was itself backpatched to pg10, though only pg15 and up contain the problem because of commit 9c08aea6a309. This isn't a particularly significant leak, but given the fix is trivial, we might as well backpatch to all branches where it applies, so do that. Author: Nathan Bossart Reported-by: Andres Freund Discussion: https://postgr.es/m/x4odfdlrwvsjawscnqsqjpofvauxslw7b4oyvxgt5owoyf4ysn@heafjusodrz7 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f9993ac646b9db202a2aa3d18444e0971b63e21f Modified Files -- src/backend/commands/dbcommands.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Restore test coverage of LZ4Stream_gets().
Restore test coverage of LZ4Stream_gets(). In commit a45c78e32 I removed the only regression test case that reaches this function, because it turns out that we only use it if reading an LZ4-compressed blobs.toc file in a directory dump, and that is a state that has to be created manually. That seems like a bad thing to not test, not so much for LZ4Stream_gets() itself as because it means the squirrely eol_flag logic in LZ4Stream_read_internal() is not tested. The reason for the change was that I thought the lz4 program did not have any way to perform compression without explicit specification of the output file name. However, it turns out that the syntax synopsis in its man page is a lie, and if you read enough of the man page you find out that with "-m" it will do what's needful. So restore the manual compression step in that test case. Noted while testing some proposed changes in pg_dump's compression logic. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 17 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/26d1cd375f156f68e12d51ba50e39ea46ea729ff Modified Files -- src/bin/pg_dump/t/002_pg_dump.pl | 9 + 1 file changed, 9 insertions(+)
