Re: pgsql: postgres_fdw: Fix assertion in estimate_path_cost_size().
Hi, I think this bugfix needs to be backpatched to v12 too. See backtrace / repro SQL here - https://www.postgresql.org/message-id/17713-92cce66de7e81c04%40postgresql.org - Robins Tharakan Amazon Web Services On Fri, 5 Feb 2021 at 17:05, Etsuro Fujita wrote: > > postgres_fdw: Fix assertion in estimate_path_cost_size(). > > Commit 08d2d58a2 added an assertion assuming that the retrieved_rows > estimate for a foreign relation, which is re-used to cost pre-sorted > foreign paths with local stats, is set to at least one row in > estimate_path_cost_size(), which isn't correct because if the relation > is a foreign table with tuples=0, the estimate would be set to 0 there > when not using remote estimates. > > Per bug #16807 from Alexander Lakhin. Back-patch to v13 where the > aforementioned commit went in. > > Author: Etsuro Fujita > Reviewed-by: Kyotaro Horiguchi > Discussion: https://postgr.es/m/16807-9fe4e08fbaa5c7ce%40postgresql.org > > Branch > -- > REL_13_STABLE > > Details > --- > https://git.postgresql.org/pg/commitdiff/984384129bb8a92481d4f7ddd5dede2d781b191f > > Modified Files > -- > contrib/postgres_fdw/expected/postgres_fdw.out | 18 ++ > contrib/postgres_fdw/postgres_fdw.c| 2 +- > contrib/postgres_fdw/sql/postgres_fdw.sql | 12 > 3 files changed, 31 insertions(+), 1 deletion(-) >
pgsql: Get rid of recursion-marker values in enum AlterTableType
Get rid of recursion-marker values in enum AlterTableType During ALTER TABLE execution, when prep-time handling of subcommands of certain types determine that execution-time handling requires recursion, they signal this by changing the subcommand type to a special value. This can be done in a simpler way by using a separate flag introduced by commit ec0925c22a3d, so do that. Catversion bumped. It's not clear to me that ALTER TABLE subcommands are stored anywhere in catalogs (CREATE FUNCTION rejects it in BEGIN ATOMIC function bodies), but we do have both write and read support for them, so be safe. Discussion: https://postgr.es/m/20220929090033.zxuaezcdwh2fgfjb@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/840ff5f451cd9a391d237fc60894fea7ad82a189 Modified Files -- src/backend/commands/tablecmds.c | 67 +- src/backend/parser/parse_utilcmd.c | 2 - src/include/catalog/catversion.h | 2 +- src/include/nodes/parsenodes.h | 5 -- .../modules/test_ddl_deparse/test_ddl_deparse.c| 20 ++- 5 files changed, 18 insertions(+), 78 deletions(-)
pgsql: Order getopt arguments
Order getopt arguments Order the letters in the arguments of getopt() and getopt_long(), as well as in the subsequent switch statements. In most cases, I used alphabetical with lower case first. In a few cases, existing different orders (e.g., upper case first) was kept to reduce the diff size. Discussion: https://www.postgresql.org/message-id/flat/3efd0fe8-351b-f836-9122-886002602357%40enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/df8b8968d4095f44acd6de03b4add65f9709b79d Modified Files -- src/backend/bootstrap/bootstrap.c| 52 +++--- src/backend/postmaster/postmaster.c | 56 +++--- src/backend/tcop/postgres.c | 54 +++--- src/bin/pg_amcheck/pg_amcheck.c | 10 +- src/bin/pg_archivecleanup/pg_archivecleanup.c| 2 +- src/bin/pg_basebackup/pg_basebackup.c| 108 ++-- src/bin/pg_basebackup/pg_receivewal.c| 41 +++-- src/bin/pg_basebackup/pg_recvlogical.c | 8 +- src/bin/pg_checksums/pg_checksums.c | 14 +- src/bin/pg_upgrade/option.c | 2 +- src/bin/pgbench/pgbench.c| 206 +++ src/bin/scripts/clusterdb.c | 38 ++--- src/bin/scripts/createdb.c | 44 ++--- src/bin/scripts/dropdb.c | 20 +-- src/bin/scripts/dropuser.c | 14 +- src/bin/scripts/reindexdb.c | 56 +++--- src/bin/scripts/vacuumdb.c | 98 +-- src/interfaces/ecpg/preproc/ecpg.c | 91 +- src/test/modules/libpq_pipeline/libpq_pipeline.c | 8 +- 19 files changed, 458 insertions(+), 464 deletions(-)
pgsql: Fix failure to advance content pointer in sendFileWithContent.
Fix failure to advance content pointer in sendFileWithContent. If sendFileWithContent were used to send a file larger than the bbsink buffer size, this would result in corruption. The only files that are sent via sendFileWithContent are the backup label file, the tablespace map file, and .done files for WAL segments included in the backup. Of these, it seems that only the tablespace_map file can become large enough to cause a problem, and then only if you have a lot of tablespaces. If you do have that situation, you might end up with a corrupted tablespace_map file, which would be bad. My commit bef47ff85df18bf4a3a9b13bd2a54820e27f3614 introduced this problem. Report and patch by Antonin Houska. Discussion: http://postgr.es/m/15764.1670528645@antos Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8b5ba2f3f40a9c82623a19b551bc5790a84275a2 Modified Files -- src/backend/backup/basebackup.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Fix failure to advance content pointer in sendFileWithContent.
Fix failure to advance content pointer in sendFileWithContent. If sendFileWithContent were used to send a file larger than the bbsink buffer size, this would result in corruption. The only files that are sent via sendFileWithContent are the backup label file, the tablespace map file, and .done files for WAL segments included in the backup. Of these, it seems that only the tablespace_map file can become large enough to cause a problem, and then only if you have a lot of tablespaces. If you do have that situation, you might end up with a corrupted tablespace_map file, which would be bad. My commit bef47ff85df18bf4a3a9b13bd2a54820e27f3614 introduced this problem. Report and patch by Antonin Houska. Discussion: http://postgr.es/m/15764.1670528645@antos Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/45f5c81ad2bc2cd4e6a4fa0ba13b34f5c6048d44 Modified Files -- src/backend/backup/basebackup.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Remove extra space from dumped ALTER DEFAULT PRIVILEGES.
Remove extra space from dumped ALTER DEFAULT PRIVILEGES. Author: Nathan Bossart Discussion: https://postgr.es/m/20221206232744.GA3560301@nathanxps13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2af33369e7940770cb81c0a9b7d3ec874ee8cb22 Modified Files -- src/bin/pg_dump/dumputils.c | 12 +--- src/bin/pg_dump/t/002_pg_dump.pl | 10 +- 2 files changed, 14 insertions(+), 8 deletions(-)
pgsql: Better document logical replication parameters
Better document logical replication parameters Add some cross-links between chapter "20. Server Parameters" and "31. Logical Replication" regarding the available configuration parameters, for easier navigation; and some more explanatory text too. I (Álvaro) chose to duplicate max_replication_slots in Chapter 20, because it has completely different meanings at each side of the replication link. Author: Peter Smith Reviewed-by: vignesh C Reviewed-by: samay sharma Discussion: https://postgr.es/m/cahut+psesqpy7w3y6cx98c255zucjvipkhkjy6hzbjov4e6...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a8500750ca0acf6bb95cf9d1ac7f421749b22db7 Modified Files -- doc/src/sgml/config.sgml | 66 --- doc/src/sgml/logical-replication.sgml | 86 ++- 2 files changed, 114 insertions(+), 38 deletions(-)
pgsql: Disable clang 16's -Wcast-function-type-strict.
Disable clang 16's -Wcast-function-type-strict. Clang 16 is still in development, but seawasp reveals that it has started warning about many of our casts of function pointers (those introduced by commit 1c27d16e, and some older ones). Disable the new warning for now, since otherwise buildfarm animal seawasp fails, and we have no current plans to change our strategy for these callback function types. May be back-patched with other Clang/LLVM 16 changes around release time. Discussion: https://postgr.es/m/CA%2BhUKGJvX%2BL3aMN84ksT-cGy08VHErRNip3nV-WmTx7f6Pqhyw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/101c37cd342a3ae134bb3e5e0abb14ae46692b56 Modified Files -- configure| 44 configure.ac | 6 ++ meson.build | 3 +++ 3 files changed, 53 insertions(+)
pgsql: Fix jsonb subscripting to cope with toasted subscript values.
Fix jsonb subscripting to cope with toasted subscript values. jsonb_get_element() was incautious enough to use VARDATA() and VARSIZE() directly on an arbitrary text Datum. That of course fails if the Datum is short-header, compressed, or out-of-line. The typical result would be failing to match any element of a jsonb object, though matching the wrong one seems possible as well. setPathObject() was slightly brighter, in that it used VARDATA_ANY and VARSIZE_ANY_EXHDR, but that only kept it out of trouble for short-header Datums. push_path() had the same issue. This could result in faulty subscripted insertions, though keys long enough to cause a problem are likely rare in the wild. Having seen these, I looked around for unsafe usages in the rest of the adt/json* files. There are a couple of places where it's not immediately obvious that the Datum can't be compressed or out-of-line, so I added pg_detoast_datum_packed() to cope if it is. Also, remove some other usages of VARDATA/VARSIZE on Datums we just extracted from a text array. Those aren't actively broken, but they will become so if we ever start allowing short-header array elements, which does not seem like a terribly unreasonable thing to do. In any case they are not great coding examples, and they could also do with comments pointing out that we're assuming we don't need pg_detoast_datum_packed. Per report from exe-dea...@yandex.ru. Patch by me, but thanks to David Johnston for initial investigation. Back-patch to v14 where jsonb subscripting was introduced. Discussion: https://postgr.es/m/205321670615...@mail.yandex.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b0feda79fdf02710a6039a324299525845a4a9d4 Modified Files -- src/backend/utils/adt/jsonb_gin.c | 5 +++-- src/backend/utils/adt/jsonb_op.c| 10 + src/backend/utils/adt/jsonfuncs.c | 41 ++--- src/test/regress/expected/jsonb.out | 34 ++ src/test/regress/sql/jsonb.sql | 18 5 files changed, 90 insertions(+), 18 deletions(-)
pgsql: Fix jsonb subscripting to cope with toasted subscript values.
Fix jsonb subscripting to cope with toasted subscript values. jsonb_get_element() was incautious enough to use VARDATA() and VARSIZE() directly on an arbitrary text Datum. That of course fails if the Datum is short-header, compressed, or out-of-line. The typical result would be failing to match any element of a jsonb object, though matching the wrong one seems possible as well. setPathObject() was slightly brighter, in that it used VARDATA_ANY and VARSIZE_ANY_EXHDR, but that only kept it out of trouble for short-header Datums. push_path() had the same issue. This could result in faulty subscripted insertions, though keys long enough to cause a problem are likely rare in the wild. Having seen these, I looked around for unsafe usages in the rest of the adt/json* files. There are a couple of places where it's not immediately obvious that the Datum can't be compressed or out-of-line, so I added pg_detoast_datum_packed() to cope if it is. Also, remove some other usages of VARDATA/VARSIZE on Datums we just extracted from a text array. Those aren't actively broken, but they will become so if we ever start allowing short-header array elements, which does not seem like a terribly unreasonable thing to do. In any case they are not great coding examples, and they could also do with comments pointing out that we're assuming we don't need pg_detoast_datum_packed. Per report from exe-dea...@yandex.ru. Patch by me, but thanks to David Johnston for initial investigation. Back-patch to v14 where jsonb subscripting was introduced. Discussion: https://postgr.es/m/205321670615...@mail.yandex.ru Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a18328bb3395188befc2785dbbe47f0d84baf6d1 Modified Files -- src/backend/utils/adt/jsonb_gin.c | 5 +++-- src/backend/utils/adt/jsonb_op.c| 10 + src/backend/utils/adt/jsonfuncs.c | 41 ++--- src/test/regress/expected/jsonb.out | 34 ++ src/test/regress/sql/jsonb.sql | 18 5 files changed, 90 insertions(+), 18 deletions(-)
pgsql: Fix jsonb subscripting to cope with toasted subscript values.
Fix jsonb subscripting to cope with toasted subscript values. jsonb_get_element() was incautious enough to use VARDATA() and VARSIZE() directly on an arbitrary text Datum. That of course fails if the Datum is short-header, compressed, or out-of-line. The typical result would be failing to match any element of a jsonb object, though matching the wrong one seems possible as well. setPathObject() was slightly brighter, in that it used VARDATA_ANY and VARSIZE_ANY_EXHDR, but that only kept it out of trouble for short-header Datums. push_path() had the same issue. This could result in faulty subscripted insertions, though keys long enough to cause a problem are likely rare in the wild. Having seen these, I looked around for unsafe usages in the rest of the adt/json* files. There are a couple of places where it's not immediately obvious that the Datum can't be compressed or out-of-line, so I added pg_detoast_datum_packed() to cope if it is. Also, remove some other usages of VARDATA/VARSIZE on Datums we just extracted from a text array. Those aren't actively broken, but they will become so if we ever start allowing short-header array elements, which does not seem like a terribly unreasonable thing to do. In any case they are not great coding examples, and they could also do with comments pointing out that we're assuming we don't need pg_detoast_datum_packed. Per report from exe-dea...@yandex.ru. Patch by me, but thanks to David Johnston for initial investigation. Back-patch to v14 where jsonb subscripting was introduced. Discussion: https://postgr.es/m/205321670615...@mail.yandex.ru Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d79b76b10ed55ceb25377c0623f2a159ad6117b4 Modified Files -- src/backend/utils/adt/jsonb_gin.c | 5 +++-- src/backend/utils/adt/jsonb_op.c| 10 + src/backend/utils/adt/jsonfuncs.c | 41 ++--- src/test/regress/expected/jsonb.out | 34 ++ src/test/regress/sql/jsonb.sql | 18 5 files changed, 90 insertions(+), 18 deletions(-)
pgsql: Refactor ExecGrant_*() functions
Refactor ExecGrant_*() functions Instead of half a dozen of mostly-duplicate ExecGrant_Foo() functions, write one common function ExecGrant_generic() that can handle most of them. We already have all the information we need, such as which system catalog corresponds to which catalog table and which column is the ACL column. Reviewed-by: Andres Freund Reviewed-by: Antonin Houska Discussion: https://www.postgresql.org/message-id/flat/22c7e802-4e7d-8d87-8b71-cba95e6f4bcf%40enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/369f09e420efe27359b06b69c0265f4aec5c2134 Modified Files -- src/backend/catalog/aclchk.c | 1050 +- 1 file changed, 124 insertions(+), 926 deletions(-)
