summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-05-22In ExecInitModifyTable, don't scribble on the source plan.Tom Lane
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 <[email protected]> Author: Andres Freund <[email protected]> Co-authored-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-22Fix memory leak in XMLSERIALIZE(... INDENT).Tom Lane
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 <[email protected]> Reviewed-by: Jim Jones <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 16
2025-05-22pg_dump: Adjust reltuples from 0 to -1 for dumps of older versions.Nathan Bossart
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 <[email protected]> Reviewed-by: Jeff Davis <[email protected]> Reviewed-by: Corey Huinker <[email protected]> Discussion: https://postgr.es/m/CAAeiqZ0o2p4SX5_xPcuAbbsmXjg6MJLNuPYSLUjC%3DWh-VeW64A%40mail.gmail.com
2025-05-22Revert "Don't lock partitions pruned by initial pruning"Amit Langote
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 <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-21doc: Move documentation of md5_password_warnings to a better placePeter Eisentraut
Commit db6a4a985bc categorized md5_password_warnings as an authentication setting, and the placement in postgresql.conf.sample matches that, but in the documentation it ended up under logging settings, which isn't unreasonable but inconsistent. This moves the documentation chunk to authentication settings as well.
2025-05-21Adjust operation names of pg_aios to match the documentationMichael Paquier
pg_aios used the terms "read" and "write" for vectored I/O read and write operations, respectively. The documentation refers to them as "readv" and "writev", and the code uses internally the terms PGAIO_OP_READV and PGAIO_OP_WRITEV for them, as of "vectored". This commit adjusts these operation names to match with the code and the documentation. Oversight in 8e293e689bab. Author: Atsushi Torikoshi <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-21Fix incorrect WAL description for PREPARE TRANSACTION record.Fujii Masao
Since commit 8b1dccd37c7, the PREPARE TRANSACTION WAL record includes information about dropped statistics entries. However, the WAL resource manager description function for PREPARE TRANSACTION record failed to parse this information correctly and always assumed there were no such entries. As a result, for example, pg_waldump could not display the dropped statistics entries stored in PREPARE TRANSACTION records. The root cause was that ParsePrepareRecord() did not set the number of statistics entries to drop on commit or abort. These values remained zero-initialized and were never updated from the parsed record. This commit fixes the issue by properly setting those values during parsing. With this fix, pg_waldump can now correctly report dropped statistics entries in PREPARE TRANSACTION records. Back-patch to v15, where commit 8b1dccd37c7 was introduced. Author: Daniil Davydov <[email protected]> Reviewed-by: Fujii Masao <[email protected]> Discussion: https://postgr.es/m/CAJDiXgh-6Epb2XiJe4uL0zF-cf0_s_7Lw1TfEHDMLzYjEmfGOw@mail.gmail.com Backpatch-through: 15
2025-05-21Fix regression with location calculation of nested statementsMichael Paquier
The statement location calculated for some nested query cases was wrong when multiple queries are sent as a single string, these being separated by semicolons. As pointed by Sami Imseih, the location calculation was incorrect when the last query of nested statement with multiple queries does **NOT** finish with a semicolon for the last statement. In this case, the statement length tracked by RawStmt is 0, which is equivalent to say that the string should be used until its end. The code previously discarded this case entirely, causing the location to remain at 0, the same as pointing at the beginning of the string. This caused pg_stat_statements to store incorrect query strings. This issue has been introduced in 499edb09741b. I have looked at the diffs generated by pgaudit back then, and noticed the difference generated for this nested query case, but I have missed the point that it was an actual regression with an existing case. A test case is added in pg_stat_statements to provide some coverage, restoring the pre-17 behavior for the calculation of the query locations. Special thanks to David Steele, who, through an analysis of the test diffs generated by pgaudit with the new v18 logic, has poked me about the fact that my original analysis of the matter was wrong. The test output of pg_overexplain is updated to reflect the new logic, as the new locations refer to the beginning of the argument passed to the function explain_filter(). When the module was introduced in 8d5ceb113e3f, which was after 499edb09741b (for the new calculation method), the locations of the test were not actually right: the plan generated for the query string given in input of the function pointed to the top-level query, not the nested one. Reported-by: David Steele <[email protected]> Author: Michael Paquier <[email protected]> Reviewed-by: Anthonin Bonnefoy <[email protected]> Reviewed-by: Jian He <[email protected]> Reviewed-by: Sami Imseih <[email protected]> Reviewed-by: David Steele <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-20pg_dump: Fix array literals in fetchAttributeStats().Nathan Bossart
Presently, fetchAttributeStats() builds array literals by treating the elements as SQL identifiers. This is incorrect for a couple of reasons: * Array literal content must match the external text representation of the array, i.e., what array_out() would return. One notable problem is that double quotes are escaped with "" in identifiers but with \" in array literals. To fix, build the array content using the pre-existing appendPGArray() function. * Array literals must be written as string constants. A notable problem here is that single quotes are escaped via '' in strings but are not escaped in the text representation of an array. To fix, append the aforementioned array literal content to the query with appendStringLiteralAH(). While at it, modify a test case to use an identifier that would cause the test to fail without this change. Oversight in commit 9c02e3a986. Reported-by: Philippe Beaudoin <[email protected]> Author: Jian He <[email protected]> Co-authored-by: Nathan Bossart <[email protected]> Co-authored-by: Stepan Neretin <[email protected]> Reviewed-by: Tom Lane <[email protected]> Bug: #18923 Discussion: https://postgr.es/m/18923-e79273f87c6bed69%40postgresql.org
2025-05-20Fix cross-version upgrade test failureHeikki Linnakangas
Commit 29f7ce6fe7 added another view that needs adjustment in the cross-version upgrade test. This should fix the XversionUpgrade failures in the buildfarm. Backpatch-through: 16 Discussion: https://www.postgresql.org/message-id/[email protected]
2025-05-20doc: Clarify use of _ccnew and _ccold in REINDEX CONCURRENTLYMichael Paquier
Invalid indexes are suffixed with "_ccnew" or "_ccold". The documentation missed to mention the initial underscore. ChooseRelationName() may also append an extra number if indexes with a similar name already exist; let's add a note about that too. Author: Alec Cozens <[email protected]> Discussion: https://postgr.es/m/174733277404.1455388.11471370288789479593@wrigleys.postgresql.org Backpatch-through: 13
2025-05-20aio: Fix possible state confusions due to interrupt processingAndres Freund
elog()/ereport() process interrupts, iff the log message is < ERROR and the log message will be emitted. aio's debug messages are emitted via ereport(), but in some places the code is not ready for interrupts to be processed. Fix the issue using a few different methods: 1) handle interrupts arriving concurrently - in some places it's easy to detect that by fetching the handle's generation a bit earlier 2) Check if interrupts made the work needing to be done obsolete 3) Disallow interrupts, as there's no sane way to make interrupt processing safe To prevent some similar issues from being re-introduced, assert that interrupts are held in pgaio_io_update_state(). This commit also fixes the contents of a debug message I added in 039bfc457e4. Reported-by: Alexander Lakhin <[email protected]> Reviewed-by: Noah Misch <[email protected]> Discussion: https://postgr.es/m/mvpm7ga3dfgz7bvum22hmuz26cariylmcppb3irayftc7bwk3r@l7gb6gr7azhc
2025-05-19Fix deparsing FETCH FIRST <expr> ROWS WITH TIESHeikki Linnakangas
In the grammar, <expr> is a c_expr, which accepts only a limited set of integer literals and simple expressions without parens. The deparsing logic didn't quite match the grammar rule, and failed to use parens e.g. for "5::bigint". To fix, always surround the expression with parens. Would be nice to omit the parens in simple cases, but unfortunately it's non-trivial to detect such simple cases. Even if the expression is a simple literal 123 in the original query, after parse analysis it becomes a FuncExpr with COERCE_IMPLICIT_CAST rather than a simple Const. Reported-by: yonghao lee Backpatch-through: 13 Discussion: https://www.postgresql.org/message-id/[email protected]
2025-05-19Don't retreat slot's confirmed_flush LSN.Amit Kapila
Prevent moving the confirmed_flush backwards, as this could lead to data duplication issues caused by replicating already replicated changes. This can happen when a client acknowledges an LSN it doesn't have to do anything for, and thus didn't store persistently. After a restart, the client can send the prior LSN that it stored persistently as an acknowledgement, but we need to ignore such an LSN to avoid retreating confirm_flush LSN. Diagnosed-by: Zhijie Hou <[email protected]> Author: shveta malik <[email protected]> Reviewed-by: Amit Kapila <[email protected]> Reviewed-by: Dilip Kumar <[email protected]> Tested-by: Nisha Moond <[email protected]> Backpatch-through: 13 Discussion: https://postgr.es/m/CAJpy0uDZ29P=BYB1JDWMCh-6wXaNqMwG1u1mB4=10Ly0x7HhwQ@mail.gmail.com Discussion: https://postgr.es/m/OS0PR01MB57164AB5716AF2E477D53F6F9489A@OS0PR01MB5716.jpnprd01.prod.outlook.com
2025-05-19Doc: add pre-branch task to run src/tools/copyright.pl.Tom Lane
It's common for some files with last year's copyright date to sneak into the tree between early January (when we normally run copyright.pl) and feature freeze. Immediately before branching the new release is an ideal time to fix the stragglers, so add a note about it to the RELEASE_CHANGES checklist. Discussion: https://postgr.es/m/CALa6HA4_Wu7-2PV0xv-Q84cT8eG7rTx6bdjUV0Pc=McAwkNMfQ@mail.gmail.com
2025-05-19Fix incorrect year in some copyright noticesMichael Paquier
A couple of new files have been added in the tree with a copyright year of 2024 while we were already in 2025. These should be marked with 2025, so let's fix them. Reported-by: Shaik Mohammad Mujeeb <[email protected]> Discussion: https://postgr.es/m/CALa6HA4_Wu7-2PV0xv-Q84cT8eG7rTx6bdjUV0Pc=McAwkNMfQ@mail.gmail.com
2025-05-19ecpg: Add missing newline in meson.buildMichael Paquier
Noticed while performing a routine sanity check of the files in the tree. Issue introduced by 28f04984f0c2. Discussion: https://postgr.es/m/CALa6HA4_Wu7-2PV0xv-Q84cT8eG7rTx6bdjUV0Pc=McAwkNMfQ@mail.gmail.com
2025-05-18Fix tuple_fraction calculation in generate_orderedappend_paths()Alexander Korotkov
6b94e7a6da adjusted generate_orderedappend_paths() to consider fractional paths. However, it didn't manage to interpret the tuple_fraction value correctly. According to the header comment of grouping_planner(), the tuple_fraction >= 1 specifies the absolute number of expected tuples. That number must be divided by the expected total number of tuples to get the actual fraction. Even though this is a bug fix, we don't backpatch it. The risks of the side effects of plan changes on stable branches are too high. Reported-by: Andrei Lepikhov <[email protected]> Discussion: https://postgr.es/m/3ca271fa-ca5c-458c-8934-eb148622b270%40gmail.com Author: Andrei Lepikhov <[email protected]> Reviewed-by: Junwang Zhao <[email protected]> Reviewed-by: Alvaro Herrera <[email protected]> Reviewed-by: Tom Lane <[email protected]>
2025-05-18Make our usage of memset_s() conform strictly to the C11 standard.Tom Lane
Per the letter of the C11 standard, one must #define __STDC_WANT_LIB_EXT1__ as 1 before including <string.h> in order to have access to memset_s(). It appears that many platforms are lenient about this, because we weren't doing it and yet the code appeared to work anyway. But we now find that with -std=c11, macOS is strict and doesn't declare memset_s, leading to compile failures since we try to use it anyway. (Given the lack of prior reports, perhaps this is new behavior in the latest SDK? No matter, we're clearly in the wrong.) In addition to the immediate problem, which could be fixed merely by adding the needed #define to explicit_bzero.c, it seems possible that our configure-time probe for memset_s() could fail in case a platform implements the function in some odd way due to this spec requirement. This concern can be fixed in largely the same way that we dealt with strchrnul() in 6da2ba1d8: switch to using a declaration-based configure probe instead of a does-it-link probe. Back-patch to v13 where we started using memset_s(). Reported-by: Lakshmi Narayana Velayudam <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CAA4pTnLcKGG78xeOjiBr5yS7ZeE-Rh=FaFQQGOO=nPzA1L8yEA@mail.gmail.com Backpatch-through: 13
2025-05-18Fix function name reference in commentDaniel Gustafsson
Ensure that we refer to the function being used, rather than the name of the resulting function in question. Author: Paul A Jungwirth <[email protected]> Reviewed-by: Daniel Gustafsson <[email protected]> Discussion: https://postgr.es/m/CA+renyVZNiHEv5ceKDjA4j5xC6NT6mRuW33BDERBQMi_90_t6A@mail.gmail.com
2025-05-16Align organization wording in copyright statementDaniel Gustafsson
This aligns the copyright and legal notice wordig with commit a233a603bab8 and pgweb commit 2d764dbc083ab8. Backpatch down to all supported versions. Author: Daniel Gustafsson <[email protected]> Reviewed-by: Dave Page <[email protected]> Reviewed-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13
2025-05-15Fix Assert failure in XMLTABLE parserRichard Guo
In an XMLTABLE expression, columns can be marked NOT NULL, and the parser internally fabricates an option named "is_not_null" to represent this. However, the parser also allows users to specify arbitrary option names. This creates a conflict: a user can explicitly use "is_not_null" as an option name and assign it a non-Boolean value, which violates internal assumptions and triggers an assertion failure. To fix, this patch checks whether a user-supplied name collides with the internally reserved option name and raises an error if so. Additionally, the internal name is renamed to "__pg__is_not_null" to further reduce the risk of collision with user-defined names. Reported-by: Евгений Горбанев <[email protected]> Author: Richard Guo <[email protected]> Reviewed-by: Alvaro Herrera <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 15
2025-05-14Add explicit initialization for all PlannerGlobal fieldsRichard Guo
When creating a new PlannerGlobal node in standard_planner(), most fields are explicitly initialized, but a few are not. This doesn't cause any functional issues, as makeNode() zeroes all fields by default. However, the inconsistency is undesirable from a clarity and maintenance perspective. This patch explicitly initializes the remaining fields to improve consistency and readability. Author: Richard Guo <[email protected]> Reviewed-by: David Rowley <[email protected]> Discussion: https://postgr.es/m/CAMbWs4-TgQHNOiouqGcuHoBqbJjWyx4UxGKxUY3FrF4trGbcPA@mail.gmail.com
2025-05-13Fix order of parameters in POD documentationDaniel Gustafsson
The documentation for log_check() had the parameters in the wrong order. Also while there, rename %parameters to %params to better documentation for similar functions which use %params. Backpatch down to v14 where this was introduced. Author: Daniel Gustafsson <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14
2025-05-13Fix the race condition in the test added by 7c99dc587.Amit Kapila
After executing ALTER SUBSCRIPTION tap_sub SET PUBLICATION, we did not wait for the new walsender process to restart. As a result, an INSERT executed immediately after the ALTER could be decoded and skipped, considering it is not part of any subscribed publication. And, the old apply worker could also confirm the LSN of such an INSERT. This could cause the replication to resume from a point after the INSERT. In such cases, we miss the expected warning about the missing publication. To fix this, ensure the walsender has restarted before continuing after ALTER SUBSCRIPTION. Reported-by: Tom Lane as per CI Author: vignesh C <[email protected]> Reviewed-by: Xuneng Zhou <[email protected]> Reviewed-by: Amit Kapila <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-11Add tab-complete for ALTER DOMAIN ADD [CONSTRAINT]Álvaro Herrera
We can add tab-completion with "CHECK (" and "NOT NULL" after ALTER DOMAIN ADD [CONSTRAINT]. ALTER DOMAIN dom ADD -> CHECK ( ALTER DOMAIN dom ADD -> NOT NULL ALTER DOMAIN dom ADD -> CONSTRAINT ALTER DOMAIN dom ADD CONSTRAINT nm -> CHECK ( ALTER DOMAIN dom ADD CONSTRAINT nm -> NOT NULL Author: jian he <[email protected]> Author: Dagfinn Ilmari Mannsåker <[email protected]> Discussion: https://postgr.es/m/CACJufxG_f6LzAT_McC-kKmQWpuWnOYKyNBw8Kv3xzTjPqmeHcA@mail.gmail.com
2025-05-11Fix comment of tsquerysend()Álvaro Herrera
The comment describes the order in which fields are sent, and it had one of the fields in the wrong place. This has been wrong since e6dbcb72fafa (2008), so backpatch all the way back. Author: Emre Hasegeli <[email protected]> Discussion: https://postgr.es/m/CAE2gYzzf38bR_R=izhpMxAmqHXKeM5ajkmukh4mNs_oXfxcMCA@mail.gmail.com
2025-05-11relcache: Avoid memory leak on tables with no CHECK constraintsÁlvaro Herrera
As complained about by Valgrind, in commit a379061a22a8 I failed to realize that I was causing rd_att->constr->check to become allocated when no CHECK constraints exist; previously it'd remain NULL. (This was my bug, not the mentioned commit author's). Fix by making the allocation conditional, and set ->check to NULL if unallocated. Reported-by: Yasir <[email protected]> Reviewed-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-11Sort includes in alphabetical orderÁlvaro Herrera
Added by commit 042a66291b04, no backpatch needed.
2025-05-11Fix incorrect "return NULL" in BumpAllocLarge().Tom Lane
This must be "return MemoryContextAllocationFailure(context, size, flags)" instead. The effect of this oversight is that if we got a malloc failure right here, the code would act as though MCXT_ALLOC_NO_OOM had been specified, whether it was or not. That would likely lead to a null-pointer-dereference crash at the unsuspecting call site. Noted while messing with a patch to improve our Valgrind leak detection support. Back-patch to v17 where this code came in.
2025-05-10Remove GLOBALTABLESPACE_OID assert for locked buffers.Noah Misch
Commit f4ece891fc2f3f96f0571720a1ae30db8030681b added the assertion in an attempt to catch some defects even after VACUUM FULL or REINDEX. However, IsCatalogTextUniqueIndexOid(tag.relNumber) always returns false after a relfilenode change, provoking unintended assertion failures. Reported-by: Adam Guo <[email protected]> Reviewed-by: Masahiko Sawada <[email protected]> Bug: #18912 Discussion: https://postgr.es/m/[email protected]
2025-05-10doc PG 18 relnotes: mv. hash joins and GROUP BY item to GeneralBruce Momjian
Reported-by: David Rowley Discussion: https://postgr.es/m/CAApHDvqJz+Zf7a6abisqoTGottDSRD+YPx=aQSgCsCKD476vGA@mail.gmail.com
2025-05-10aio: Use runtime arguments with injections points in testsMichael Paquier
This cleans up the code related to the testing infrastructure of AIO that used injection points, switching the test code to use the new facility for injection points added by 371f2db8b05e rather than tweaks to pass and reset arguments to the callbacks run. This removes all the dependencies to USE_INJECTION_POINTS in the AIO code. pgaio_io_call_inj(), pgaio_inj_io_get() and pgaio_inj_cur_handle are now gone. Reviewed-by: Greg Burd <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-09injection_points: Add support and tests for runtime argumentsMichael Paquier
This commit provides some test coverage for the runtime arguments of injection points, for both INJECTION_POINT_CACHED() and INJECTION_POINT(), as extended in 371f2db8b05e. The SQL functions injection_points_cached() and injection_points_run() are extended so as it is possible to pass an optional string value to them. Reviewed-by: Greg Burd <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-09Add support for runtime arguments in injection pointsMichael Paquier
The macros INJECTION_POINT() and INJECTION_POINT_CACHED() are extended with an optional argument that can be passed down to the callback attached when an injection point is run, giving to callbacks the possibility to manipulate a stack state given by the caller. The existing callbacks in modules injection_points and test_aio have their declarations adjusted based on that. da7226993fd4 (core AIO infrastructure) and 93bc3d75d8e1 (test_aio) and been relying on a set of workarounds where a static variable called pgaio_inj_cur_handle is used as runtime argument in the injection point callbacks used by the AIO tests, in combination with a TRY/CATCH block to reset the argument value. The infrastructure introduced in this commit will be reused for the AIO tests, simplifying them. Reviewed-by: Greg Burd <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-09doc PG 18 relnotes: fix missing parens for crc32c()Bruce Momjian
Reported-by: Steven Niu Discussion: https://postgr.es/m/CABBtG=ejqK58cFWpw3etVZfQfhjC-qOqV+9GQWRnLO+p9wYMbw@mail.gmail.com
2025-05-09Skip RSA-PSS ssl test when using LibreSSL.Tom Lane
Presently, LibreSSL does not have working support for RSA-PSS, so disable that test. Per discussion at https://marc.info/?l=libressl&m=174664225002441&w=2 they do intend to fix this, but it's a ways off yet. Reported-by: Thomas Munro <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Daniel Gustafsson <[email protected]> Discussion: https://postgr.es/m/CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com Backpatch-through: 15
2025-05-09Hack one ssl test case to pass with current LibreSSL.Tom Lane
With LibreSSL, our test of error logging for cert chain depths > 0 reports the wrong certificate. This is almost certainly their bug not ours, so just tweak the test to accept their answer. No back-patch needed, since this test case wasn't enabled before e0f373ee4. Reported-by: Thomas Munro <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Daniel Gustafsson <[email protected]> Discussion: https://postgr.es/m/CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com
2025-05-09Centralize ssl tests' check for whether we're using LibreSSL.Tom Lane
Right now there's only one caller, so that this is merely an exercise in shoving code from one module to another, but there will shortly be another one. It seems better to avoid having two copies of this highly-subject-to-change test. Back-patch to v15, where we first introduced some tests that don't work with LibreSSL. Reported-by: Thomas Munro <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Daniel Gustafsson <[email protected]> Discussion: https://postgr.es/m/CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com Backpatch-through: 15
2025-05-09doc: Put new options in consistent order on man pagesPeter Eisentraut
2025-05-08Use 'void *' for arbitrary buffers, 'uint8 *' for byte arraysHeikki Linnakangas
A 'void *' argument suggests that the caller might pass an arbitrary struct, which is appropriate for functions like libc's read/write, or pq_sendbytes(). 'uint8 *' is more appropriate for byte arrays that have no structure, like the cancellation keys or SCRAM tokens. Some places used 'char *', but 'uint8 *' is better because 'char *' is commonly used for null-terminated strings. Change code around SCRAM, MD5 authentication, and cancellation key handling to follow these conventions. Discussion: https://www.postgresql.org/message-id/[email protected]
2025-05-08Use more mundane 'int' type for cancel key lengths in libpqHeikki Linnakangas
The documented max length of a cancel key is 256 bytes, so it fits in uint8. It nevertheless seems weird to not just use 'int', like in commit 0f1433f053 for the backend. Discussion: https://www.postgresql.org/message-id/61be9e31-7b7d-49d5-bc11-721800d89d64%40eisentraut.org
2025-05-08PG 18 relnotes: adjust RETURNING new/old itemBruce Momjian
Reported-by: jian he Discussion: https://postgr.es/m/CACJufxFM1avdwu=OrTx_uMAjTDbFOj1Gp7mnNHOofTVj9QtmRw@mail.gmail.com
2025-05-08doc: Fix title markup for AT TIME ZONE and AT LOCALDaniel Gustafsson
The title for AT TIME ZONE and AT LOCAL was accidentally wrapping the "and" in the <literal> tag. Backpatch to v17 where it was introduced in 97957fdbaa42. Author: Noboru Saito <[email protected]> Reviewed-by: Daniel Gustafsson <[email protected]> Reviewed-by: Tatsuo Ishii <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/CAAM3qn+7QUWW9R6_YwPKXmky0xGE4n63U3EsxZeWE_QtogeU8g@mail.gmail.com Backpatch-through: 17
2025-05-08Track the number of presorted outer pathkeys in MergePathRichard Guo
When creating an explicit Sort node for the outer path of a mergejoin, we need to determine the number of presorted keys of the outer path to decide whether explicit incremental sort can be applied. Currently, this is done by repeatedly calling pathkeys_count_contained_in. This patch caches the number of presorted outer pathkeys in MergePath, allowing us to save several calls to pathkeys_count_contained_in. It can be considered a complement to the changes in commit 828e94c9d. Reported-by: David Rowley <[email protected]> Author: Richard Guo <[email protected]> Reviewed-by: Tender Wang <[email protected]> Discussion: https://postgr.es/m/CAApHDvqvBireB_w6x8BN5txdvBEHxVgZBt=rUnpf5ww5P_E_ww@mail.gmail.com
2025-05-08Suppress unnecessary explicit sorting for EPQ mergejoin pathRichard Guo
When building a ForeignPath for a joinrel, if there's a possibility that EvalPlanQual will be executed, we must identify a suitable path for EPQ checks. If the outer or inner path of the chosen path is a ForeignPath representing a pushed-down join, we replace it with its fdw_outerpath to ensure that the EPQ check path consists entirely of local joins. If the chosen path is a MergePath, and its outer or inner path is a ForeignPath that is not already well enough ordered, the MergePath will have non-NIL outersortkeys or innersortkeys indicating the desired ordering to be created by an explicit Sort node. If we then replace the outer or inner path with its corresponding fdw_outerpath, and that path is already sufficiently ordered, we end up in an inconsistent state: the MergePath has non-NIL outersortkeys or innersortkeys, and its input path is already properly ordered. This inconsistency can result in an Assert failure or the addition of a redundant Sort node. To fix, check if the new outer or inner path of a MergePath is already properly sorted, and set its outersortkeys or innersortkeys to NIL if so. Bug: #18902 Reported-by: Nikita Kalinin <[email protected]> Author: Richard Guo <[email protected]> Reviewed-by: Tender Wang <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-05-08doc PG 18 relnotes: adjust pg_log_backend_memory_contexts()Bruce Momjian
Reported-by: David Rowley Discussion: https://postgr.es/m/CAApHDvrGLBqs_Vm9COMY7uBDvUDMKds7RwC20YjEPf+XRTY9XQ@mail.gmail.com
2025-05-08doc PG 18 relnotes: add pg_log_backend_memory_contexts() mentionBruce Momjian
Now zero-based. Reported-by: David Rowley Discussion: https://postgr.es/m/CAApHDvqMfTBdfwc0Z-tHXLnBMKJLYEZDApgUzA7x_PUDZsY3GA@mail.gmail.com
2025-05-07doc PG 18 relnotes: adjust pgbench per-script reporting itemBruce Momjian
Also run src/tools/add_commit_links.pl for a previous commit. Reported-by: Yugo Nagata Discussion: https://postgr.es/m/[email protected]
2025-05-07doc PG 18 relnotes: mention GROUP SET fixesBruce Momjian
Reported-by: Richard Guo Discussion: https://postgr.es/m/CAMbWs4_asKPqTCt0h9pp=zHc9vmPcnczbHeF6Xkxn1LhLapcTQ@mail.gmail.com