pgsql: pg_dump: Adjust reltuples from 0 to -1 for dumps of older versio
pg_dump: Adjust reltuples from 0 to -1 for dumps of older versions. Before v14, a reltuples value of 0 was ambiguous: it could either mean the relation is empty, or it could mean that it hadn't yet been vacuumed or analyzed. (Commit 3d351d916b taught v14 and newer to use -1 for the latter case.) This ambiguity allegedly can cause the planner to choose inefficient plans after restoring to v18 or newer. To fix, let's just dump reltuples as -1 in that case. This will cause some truly empty tables to be seen as not-yet-processed, but that seems unlikely to cause too much trouble in practice. Note that we could alternatively teach pg_restore_relation_stats() to translate reltuples based on the version argument, but since that function doesn't exist until v18, there's no particular advantage to that approach. That is, there's no chance of restoring stats dumped from a pre-v14 server to another pre-v14 server. Per discussion, the current policy is to fix pre-v18 behavior differences during export and everything else during import. Commit 9879105024 fixed a similar problem for vacuumdb by removing the check for reltuples != 0. Presumably we could reinstate that check now, but I've chosen to leave it in place in case reltuples isn't accurate. As before, processing some empty tables seems relatively harmless. Author: Hari Krishna Sunder Reviewed-by: Jeff Davis Reviewed-by: Corey Huinker Discussion: https://postgr.es/m/CAAeiqZ0o2p4SX5_xPcuAbbsmXjg6MJLNuPYSLUjC%3DWh-VeW64A%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5d6eac80cdce7aa7c5f4ec74208ddc1feea9eef3 Modified Files -- src/bin/pg_dump/pg_dump.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-)
GSS Auth issue when user member of lots of AD groups
Hi, GSS authentication is working for users with small number of AD groups but getting below error when a user has larger number of groups. I believe it might to token size related, but they don't have issues when authenticating with Kerberos/GSS to other applications, only with Postgres. failed: GSSAPI context establishment error: The routine must be called again to complete its function: Unknown error Is this a hard limit or can this be configurable? Also, what is the best way to debug this as the postgresql.log does not have anything useful. Running on Alma Linux 9 Thanks, Chris This email and any attachments should not be construed as an offer or recommendation to sell or buy or a solicitation of an offer to sell or buy any specific security, fund or instrument or to participate in any particular investment strategy. The information contained herein is given as of a certain date and does not purport to give information as of any other date. Although the information presented herein has been obtained from sources we believe to be reliable, no representation or warranty, expressed or implied, is made as to the accuracy or completeness of that information. Past performance is not indicative of future results. CONFIDENTIALITY NOTICE: This message and any attachment are confidential. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other persons. Balyasny Asset Management (UK) LLP is authorised and regulated by the Financial Conduct Authority in the UK. Balyasny Asset Management LP is registered as an Investment Advisor with the Securities and Exchange Commission in the USA. BAM prohibits all personnel from having any business related communications over text message or other unapproved communication applications. Unless pre-approved, BAM employees are only permitted to communicate over email, Bloomberg and BAM telephone lines.
pgsql: Remove accidentally added meson.build
Remove accidentally added meson.build Commit b4363fc66e6 added an empty meson.build to 13, presumably due to a conflict resolution while backpatching. Remove it. Discussion: https://postgr.es/m/b7angm4wz2ln2wsqvsb3bwl4pqa4xxgcawn36o5kweu5pgpl6s@ofhhrgl5ouwb Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e7480f3dd6c24ecbcd2521faf82bf85ee6e65802 Modified Files -- meson.build | 0 1 file changed, 0 insertions(+), 0 deletions(-)
pgsql: Fix memory leak in XMLSERIALIZE(... INDENT).
Fix memory leak in XMLSERIALIZE(... INDENT). xmltotext_with_options sometimes tries to replace the existing root node of a libxml2 document. In that case xmlDocSetRootElement will unlink and return the old root node; if we fail to free it, it's leaked for the remainder of the session. The amount of memory at stake is not large, a couple hundred bytes per occurrence, but that could still become annoying in heavy usage. Our only other xmlDocSetRootElement call is not at risk because it's working on a just-created document, but let's modify that code too to make it clear that it's dependent on that. Author: Tom Lane Reviewed-by: Jim Jones Discussion: https://postgr.es/m/1358967.1747858...@sss.pgh.pa.us Backpatch-through: 16 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f24605e2dc1687917766f43775f0dcde2cf678a0 Modified Files -- src/backend/utils/adt/xml.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-)
pgsql: Fix memory leak in XMLSERIALIZE(... INDENT).
Fix memory leak in XMLSERIALIZE(... INDENT). xmltotext_with_options sometimes tries to replace the existing root node of a libxml2 document. In that case xmlDocSetRootElement will unlink and return the old root node; if we fail to free it, it's leaked for the remainder of the session. The amount of memory at stake is not large, a couple hundred bytes per occurrence, but that could still become annoying in heavy usage. Our only other xmlDocSetRootElement call is not at risk because it's working on a just-created document, but let's modify that code too to make it clear that it's dependent on that. Author: Tom Lane Reviewed-by: Jim Jones Discussion: https://postgr.es/m/1358967.1747858...@sss.pgh.pa.us Backpatch-through: 16 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/20bae0690322a00402b84119ddf2f959d24a211a Modified Files -- src/backend/utils/adt/xml.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-)
pgsql: Fix memory leak in XMLSERIALIZE(... INDENT).
Fix memory leak in XMLSERIALIZE(... INDENT). xmltotext_with_options sometimes tries to replace the existing root node of a libxml2 document. In that case xmlDocSetRootElement will unlink and return the old root node; if we fail to free it, it's leaked for the remainder of the session. The amount of memory at stake is not large, a couple hundred bytes per occurrence, but that could still become annoying in heavy usage. Our only other xmlDocSetRootElement call is not at risk because it's working on a just-created document, but let's modify that code too to make it clear that it's dependent on that. Author: Tom Lane Reviewed-by: Jim Jones Discussion: https://postgr.es/m/1358967.1747858...@sss.pgh.pa.us Backpatch-through: 16 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ee58de10084b42a24aaa3ab4af7713bb2fe02ab4 Modified Files -- src/backend/utils/adt/xml.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-)
pgsql: In ExecInitModifyTable, don't scribble on the source plan.
In ExecInitModifyTable, don't scribble on the source plan. The code carelessly modified mtstate->ps.plan->targetlist, which it's not supposed to do. Fortunately, there's not really any need to do that because the planner already set up a perfectly acceptable targetlist for the plan node. We just need to remove the erroneous assignments and update some relevant comments. As it happens, the erroneous assignments caused the targetlist to point to a different part of the source plan tree, so that there isn't really a risk of the pointer becoming dangling after executor termination. The only visible effect of this change we can find is that EXPLAIN will show upper references to the ModifyTable's output expressions using different variables. Formerly it showed Vars from the first target relation that survived executor-startup pruning. Now it always shows such references using the first relation appearing in the planner output, independently of what happens during executor pruning. On the whole that seems like a good thing. Also make a small tweak in ExplainPreScanNode to ensure that the first relation will receive a refname assignment in set_rtable_names, even if it got pruned at startup. Previously the Vars might be shown without any table qualification, which is confusing in a multi-table query. I considered back-patching this, but since the bug doesn't seem to have any really terrible consequences in existing branches, it seems better to not change their EXPLAIN output. It's not too late for v18 though, especially since v18 already made other changes in the EXPLAIN output for these cases. Reported-by: Tom Lane Author: Andres Freund Co-authored-by: Tom Lane Discussion: https://postgr.es/m/213261.1747611...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d376ab570ef95f2eae13a77cbd9ba21383f195f7 Modified Files -- src/backend/commands/explain.c| 4 +++ src/backend/executor/nodeModifyTable.c| 10 +++--- src/backend/optimizer/plan/setrefs.c | 7 ++-- src/test/regress/expected/partition_prune.out | 47 +++ src/test/regress/sql/partition_prune.sql | 6 ++-- 5 files changed, 41 insertions(+), 33 deletions(-)
pgsql: Replace deprecated log_connections values in docs and tests
Replace deprecated log_connections values in docs and tests 9219093cab2607f modularized log_connections output to allow more granular control over which aspects of connection establishment are logged. It converted the boolean log_connections GUC into a list of strings and deprecated previously supported boolean-like values on, off, true, false, 1, 0, yes, and no. Those values still work, but they are supported mainly for backwards compatability. As such, documented examples of log_connections should not use these deprecated values. Update references in the docs to deprecated log_connections values. Many of the tests use log_connections. This commit also updates the tests to use the new values of log_connections. In some of the tests, the updated log_connections value covers a narrower set of aspects (e.g. the 'authentication' aspect in the tests in src/test/authentication and the 'receipt' aspect in src/test/postmaster). In other cases, the new value for log_connections is a superset of the previous included aspects (e.g. 'all' in src/test/kerberos/t/001_auth.pl). Reported-by: Peter Eisentraut Author: Melanie Plageman Reviewed-by: Peter Eisentraut Reviewed-by: Jacob Champion Discussion: https://postgr.es/m/e1586594-3b69-4aea-87ce-73a7488cdc97%40eisentraut.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cb1456423d3925f9c70a488b58f03f186561f00f Modified Files -- doc/src/sgml/config.sgml| 4 ++-- src/backend/tcop/postgres.c | 2 +- src/interfaces/libpq/t/005_negotiate_encryption.pl | 2 +- src/test/authentication/t/003_peer.pl | 2 +- src/test/authentication/t/005_sspi.pl | 2 +- src/test/authentication/t/007_pre_auth.pl | 2 +- src/test/kerberos/t/001_auth.pl | 2 +- src/test/ldap/t/001_auth.pl | 2 +- src/test/ldap/t/002_bindpasswd.pl | 2 +- src/test/modules/ldap_password_func/t/001_mutated_bindpasswd.pl | 3 ++- src/test/modules/oauth_validator/t/001_server.pl| 2 +- src/test/modules/oauth_validator/t/002_client.pl| 2 +- src/test/postmaster/t/002_connection_limits.pl | 3 ++- src/test/postmaster/t/003_start_stop.pl | 3 ++- src/test/recovery/t/013_crash_restart.pl| 2 +- src/test/recovery/t/022_crash_temp_files.pl | 2 +- src/test/recovery/t/032_relfilenode_reuse.pl| 2 +- src/test/recovery/t/037_invalid_database.pl | 2 +- src/test/ssl/t/SSL/Server.pm| 2 +- src/tools/ci/pg_ci_base.conf| 2 +- 20 files changed, 24 insertions(+), 21 deletions(-)
pgsql: Revert "Don't lock partitions pruned by initial pruning"
Revert "Don't lock partitions pruned by initial pruning" As pointed out by Tom Lane, the patch introduced fragile and invasive design around plan invalidation handling when locking of prunable partitions was deferred from plancache.c to the executor. In particular, it violated assumptions about CachedPlan immutability and altered executor APIs in ways that are difficult to justify given the added complexity and overhead. This also removes the firstResultRels field added to PlannedStmt in commit 28317de72, which was intended to support deferred locking of certain ModifyTable result relations. Reported-by: Tom Lane Discussion: https://postgr.es/m/605328.1747710...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1722d5eb05d8e5d2e064cd1798abcae4f296ca9d Modified Files -- contrib/auto_explain/auto_explain.c | 16 +- contrib/pg_stat_statements/pg_stat_statements.c | 16 +- doc/src/sgml/release-18.sgml| 21 --- src/backend/commands/copyto.c | 5 +- src/backend/commands/createas.c | 5 +- src/backend/commands/explain.c | 22 +-- src/backend/commands/extension.c| 4 +- src/backend/commands/matview.c | 5 +- src/backend/commands/portalcmds.c | 1 - src/backend/commands/prepare.c | 9 +- src/backend/commands/trigger.c | 15 -- src/backend/executor/README | 35 + src/backend/executor/execMain.c | 127 ++- src/backend/executor/execParallel.c | 12 +- src/backend/executor/execPartition.c| 66 +--- src/backend/executor/execUtils.c| 1 - src/backend/executor/functions.c| 5 +- src/backend/executor/spi.c | 29 +--- src/backend/optimizer/plan/planner.c| 2 - src/backend/optimizer/plan/setrefs.c| 3 - src/backend/tcop/postgres.c | 4 +- src/backend/tcop/pquery.c | 51 +- src/backend/utils/cache/plancache.c | 197 +++- src/backend/utils/mmgr/portalmem.c | 4 +- src/include/commands/explain.h | 6 +- src/include/commands/trigger.h | 1 - src/include/executor/execdesc.h | 2 - src/include/executor/executor.h | 34 +--- src/include/nodes/execnodes.h | 3 - src/include/nodes/pathnodes.h | 3 - src/include/nodes/plannodes.h | 7 - src/include/utils/plancache.h | 46 +- src/include/utils/portal.h | 4 +- 33 files changed, 89 insertions(+), 672 deletions(-)
pgsql: doc PG 18 relnotes: remove duplicate commit entry
doc PG 18 relnotes: remove duplicate commit entry Item related to btree skip scans. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3b7140d27e248171fc4a9a18bdfd2288054e8bde Modified Files -- doc/src/sgml/release-18.sgml | 3 --- 1 file changed, 3 deletions(-)
pgsql: doc PG 18 relnotes: clarify btree skip scan item
doc PG 18 relnotes: clarify btree skip scan item Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=2CWXgO1+uyR-VfN3ALMtFnfTtXK-VtkoQQ89ogm=4...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7ddfac79f2cd315314efb1402e896fa4386a1995 Modified Files -- doc/src/sgml/release-18.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: doc PG 18 relnotes: adjust CREATE SUBSCRIPTION attribution
doc PG 18 relnotes: adjust CREATE SUBSCRIPTION attribution Reported-by: vignesh C Discussion: https://postgr.es/m/CALDaNm0Wy-vJ6dE+e=y=yuq31i2kvgf-rs-u6qog4k7tpu_...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/883339c170d1c73162283506c85536f735e42baa Modified Files -- doc/src/sgml/release-18.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix assorted new memory leaks in libpq.
Fix assorted new memory leaks in libpq. Valgrind'ing the postgres_fdw tests showed me that libpq was leaking PGconn.be_cancel_key. It looks like freePGconn is expecting pqDropServerData to release it ... but in a cancel connection object, that doesn't happen. Looking a little closer, I was dismayed to find that freePGconn also missed freeing the pgservice, min_protocol_version, max_protocol_version, sslkeylogfile, scram_client_key_binary, and scram_server_key_binary strings. There's much less excuse for those oversights. Worse, that's from five different commits (a460251f0, 4b99fed75, 285613c60, 2da74d8d6, 761c79508), some of them by extremely senior hackers. Fortunately, all of these are new in v18, so we haven't shipped any leaky versions of libpq. While at it, reorder the operations in freePGconn to match the order of the fields in struct PGconn. Some of those free's seem to have been inserted with the aid of a dartboard. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b7ab88ddb1b9872cd997aea921df99eed8ac220b Modified Files -- src/interfaces/libpq/fe-connect.c | 44 +-- 1 file changed, 24 insertions(+), 20 deletions(-)
