aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Fix some grammatical errors in some commentsDavid Rowley2024-06-05
| | | | | | | Introduced by 9f1337639. Author: James Coleman <jtc331@gmail.com> Discussion: https://postgr.es/m/CAAaqYe9ZQ_1+QiF_Nv7b37opicBu+35ZQK1CetQ54r5UdrF1eg@mail.gmail.com
* Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().Tom Lane2024-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | In a procedure or function returning tuple, we use that function to parse the Tcl script's result, which is supposed to be a Tcl list. If it isn't, you get an error. Commit 26abb50c4 incautiously supposed that we could use throw_tcl_error() to report such an error. That doesn't actually work, because low-level functions like Tcl_ListObjGetElements() don't fill Tcl's errorInfo variable. The result is either a null-pointer-dereference crash or emission of misleading context information describing the previous Tcl error. Back off to just reporting the interpreter's result string, and improve throw_tcl_error()'s comment to explain when to use it. Also, although the similar code in pltcl_trigger_handler() avoided this mistake, it was using a fairly confusing wording of the error message. Improve that while we're here. Per report from A. Kozhemyakin. Back-patch to all supported branches. Erik Wienhold and Tom Lane Discussion: https://postgr.es/m/6a2a1c40-2b2c-4a33-8b72-243c0766fcda@postgrespro.ru
* Fix PL/pgSQL's handling of integer ranges containing underscores.Dean Rasheed2024-06-04
| | | | | | | | | | | | | | | Commit faff8f8e47 allowed integer literals to contain underscores, but failed to update the lexer's "numericfail" rule. As a result, a decimal integer literal containing underscores would fail to parse, if used in an integer range with no whitespace after the first number, such as "1_001..1_003" in a PL/pgSQL FOR loop. Fix and backpatch to v16, where support for underscores in integer literals was added. Report and patch by Erik Wienhold. Discussion: https://postgr.es/m/808ce947-46ec-4628-85fa-3dd600b2c154%40ewie.name
* Fix another couple of outdated comments for MERGE RETURNING.Dean Rasheed2024-06-04
| | | | | | Oversights in c649fa24a4 which added RETURNING support to MERGE. Discussion: https://postgr.es/m/CAApHDvpqp6vtUzG-_josUEiBGyqnrnVxJ-VdF+hJLXjHdHzsyQ@mail.gmail.com
* Improve assertion in mdwritev()Michael Paquier2024-06-04
| | | | | | | | | | | | | | | | The assertion used at the beginning of mdwritev(), that is not enabled except by defining -DCHECK_WRITE_VS_EXTEND as mdnblocks() is costly, forgot about the total number of blocks to write at location specified by the caller. The calculation is fixed to count for that, and uses casts to uint64 to ensure a proper check should the number of blocks overflow. Using a cast is a suggestion from Tom Lane. Oversight in 4908c5872059. Author: Xing Guo Discussion: https://postgr.es/m/CACpMh+BM-VgKeO7suPG-VHTtpzJ+zsbDPwVHu42PLp-iTk0z+A@mail.gmail.com
* Fix check for memory allocationDaniel Gustafsson2024-05-27
| | | | | | | | | | Commit 61461a300c1 accidentally checked memory allocation success using the wrong variable. Author: Ranier Vilela <ranier.vf@gmail.com> Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/CAEudQAqQFTH7xCB-+K6zEKjfqbhqCxcr_w4DuJTxVT6h3vzu2w@mail.gmail.com
* Fix potential NULL pointer dereference in getIdentitySequence()Michael Paquier2024-05-26
| | | | | | | | | | | | | | | | | | The function invokes SearchSysCacheAttNum() and SearchSysCacheAttName(). They may respectively return 0 for the attribute number or NULL for the attribute name if the attribute does not exist, without any kind of error handling. The common practice is to check that the data retrieved from the syscache is valid. There is no risk of NULL pointer dereferences currently, but let's stick to the practice of making sure that this data is always valid, to catch future inconsistency mistakes. The code is switched to use get_attnum() and get_attname(), and adds some error handling. Oversight in 509199587df7. Reported-by: Ranier Vilela Author: Ashutosh Bapat Discussion: https://postgr.es/m/CAEudQAqh_RZqoFcYKso5d9VhF-Vd64_ZodfQ_2zSusszkEmyRg@mail.gmail.com
* Provide deterministic order for catalog queries in partition_split.sqlAlexander Korotkov2024-05-26
| | | | | | | | | | System catalog tables are subject to modification by parallel tests. This is the source of instability when querying them without explicit ORDER BY. This commit adds explicit ORDER BY to system catalog queries in partition_split.sql to stabilize the result. Reported-by: Tom Lane Discussion: https://postgr.es/m/695264.1716578979%40sss.pgh.pa.us
* Fix comment in 024_add_drop_pub.plMichael Paquier2024-05-24
| | | | | | | | | | | A comment of the test was referring to an incorrect table. Thinko in 1046a69b3087. Extracted from a larger patch by the same author. Author: Alexander Lakhin Discussion: https://postgr.es/m/70b340bc-244a-589d-ef8b-d8aebb707a84@gmail.com
* Improve stability of subscription/029_on_error.plMichael Paquier2024-05-24
| | | | | | | | | | | | | | | | | This test was failing when using wal_debug=on and -DWAL_DEBUG because of additional log entries that made the test grab an LSN not mapping with the error expected in the test. Previously the test would look for the first matching line to get the LSN to skip up to. This is improved by having the test scan the logs with a regexp that checks for the expected ERROR string, ensuring that the wanted LSN comes from the correct context. Backpatch down to 15 where this test has been introduced. Author: Ian Ilyasov Discussion: https://postgr.es/m/GV1P251MB100415F17E6B2FDD7188777ECDE32@GV1P251MB1004.EURP251.PROD.OUTLOOK.COM Backpatch-through: 15
* Remove race conditions between ECPGdebug() and ecpg_log().Tom Lane2024-05-23
| | | | | | | | | | | | | | | | | | | | | | Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about unlocked use of simple_debug. I think it's intentional and safe to have a quick unlocked check of simple_debug at the start of ecpg_log, since that early exit will always be taken in non-debug cases. But we should recheck simple_debug after acquiring the mutex. In the worst case, calling ECPGdebug concurrently with ecpg_log in another thread could result in a null-pointer dereference due to debugstream transiently being NULL while simple_debug isn't 0. This is largely hypothetical, since it's unlikely anybody uses ECPGdebug() at all in the field, and our own regression tests don't seem to be hitting the theoretical race conditions either. Still, if we're going to the trouble of having mutexes here, we ought to be using them in a way that's actually safe not just almost safe. Hence, back-patch to all supported branches.
* jsonapi: Some message style fixesPeter Eisentraut2024-05-23
| | | | Add missing punctuation, and un-gettext-mark an internal error.
* Fix typo and comments related to the recent no-wait lock improvementsMichael Paquier2024-05-23
| | | | | | | | | | | The argument of dontWait at the top of ProcSleep() was documented backwards, and there was a typo in lock.c. Thinkos in 2346df6fc373. Author: Will Mortensen Reviewed-by: Jingxian Li, Michael Paquier Discussion: https://postgr.es/m/CAMpnoC5f+eiS7tdy8PUpd_LacSTVT-pYpVooKfjHRQQmkHPZ2g@mail.gmail.com
* Fix a couple of outdated comments now that we have MERGE RETURNINGDavid Rowley2024-05-23
| | | | | | This has been supported since c649fa24a. Discussion: https://postgr.es/m/CAApHDvpqp6vtUzG-_josUEiBGyqnrnVxJ-VdF+hJLXjHdHzsyQ@mail.gmail.com
* Don't copy extended statistics during MERGE/SPLIT partition operationsAlexander Korotkov2024-05-23
| | | | | | | | | | | | | | | | | | | | When MERGE/SPLIT created new partitions, it was cloning the extended statistics of the parent table. However, extended stats on partitioned tables don't behave like indexes on partitioned tables (which exist only to create physical indexes on child tables). Rather, extended stats on a parent 1) cause extended stats to be collected and computed across the whole partition hierarchy, and 2) do not cause extended stats to be computed for the individual partitions. "CREATE TABLE ... PARTITION OF" command doesn't copy extended statistics. This commit makes createPartitionTable() behave consistently. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/ZiJW1g2nbQs9ekwK%40pryzbyj2023 Author: Alexander Korotkov, Justin Pryzby
* Fix the name collision detection in MERGE/SPLIT partition operationsAlexander Korotkov2024-05-23
| | | | | | | | | | | | | | | | | | | | | Both MERGE and SPLIT partition operations support the case when the name of the new partition matches the name of the existing partition to be merged/split. But the name collision detection doesn't always work as intended. The SPLIT partition operation finds the namespace to search for an existing partition without taking into account the parent's persistence. The MERGE partition operation checks for the name collision with simple equal() on RangeVar's simply ignoring the search_path. This commit fixes this behavior as follows. 1. The SPLIT partition operation now finds the namespace to search for an existing partition according to the parent's persistence. 2. The MERGE partition operation now checks for the name collision similarly to the SPLIT partition operation using RangeVarGetAndCheckCreationNamespace() and get_relname_relid(). Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/86b4f1e3-0b5d-315c-9225-19860d64d685%40gmail.com Author: Dmitry Koval, Alexander Korotkov
* amcheck: Refactoring the storage of the last visible entryAlexander Korotkov2024-05-23
| | | | | | | | | | | This commit introduces a new data structure BtreeLastVisibleEntry comprising information about the last visible heap entry with the current value of key. Usage of this data structure allows us to avoid passing all this information as individual function arguments. Reported-by: Alexander Korotkov Discussion: https://www.postgresql.org/message-id/CAPpHfdsVbB9ToriaB1UHuOKwjKxiZmTFQcEF%3DjuzzC_nby31uA%40mail.gmail.com Author: Pavel Borisov, Alexander Korotkov
* Fix input of ISO "extended" time format for types time and timetz.Tom Lane2024-05-22
| | | | | | | | | | | | | | | | | | | | | | | Commit 3e1a373e2 missed teaching DecodeTimeOnly the same "ptype" manipulations it added to DecodeDateTime. While likely harmless at the time, it became a problem after 5b3c59535 added an error check that ptype must be zero once we exit the parsing loop (that is, there shouldn't be any unused prefixes). The consequence was that we'd reject time or timetz input like T12:34:56 (the "extended" format per ISO 8601-1:2019), even though that still worked in timestamp input. Since this is clearly under-tested code, add test cases covering all the ISO 8601 time formats. (Note: although 8601 allows just "Thh", we have never accepted that, and this patch doesn't change that. I'm content to leave that as-is because it seems too likely to be a mistake rather than intended input. If anyone wants to allow that, it should be a separate patch anyway, and not back-patched.) Per bug #18470 from David Perez. Back-patch to v16 where we broke it. Discussion: https://postgr.es/m/18470-34fad4c829106848@postgresql.org
* Fix handling of extended expression statistics in CREATE TABLE LIKE.Tom Lane2024-05-22
| | | | | | | | | | | | | | | | | | | | | | | transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced, but it was falsified by the addition of extended stats on expressions: the parsed expression tree is fed forward by the LIKE option, and that will contain Vars. So if the new table doesn't have attnums identical to the old one's (typically because there are some dropped columns in the old one), that doesn't work. The CREATE goes through, but it emits invalid statistics objects that will cause problems later. Fortunately, we already have logic that can adapt expression trees to the possibly-new column numbering. To use it, we have to delay processing of CREATE_TABLE_LIKE_STATISTICS into expandTableLikeClause, just as for other LIKE options that involve expressions. Per bug #18468 from Alexander Lakhin. Back-patch to v14 where extended statistics on expressions were added. Discussion: https://postgr.es/m/18468-f5add190e3fa5902@postgresql.org
* Fix generate_union_paths for non-sortable types.REL_17_BETA1Robert Haas2024-05-21
| | | | | | | | | | | | The previous logic would fail to set groupList when grouping_is_sortable() returned false, which could cause queries to return wrong answers when some columns were not sortable. David Rowley, reviewed by Heikki Linnakangas and Álvaro Herrera. Reported by Hubert "depesz" Lubaczewski. Discussion: http://postgr.es/m/Zktzf926vslR35Fv@depesz.com Discussion: http://postgr.es/m/CAApHDvra=c8_zZT0J-TftByWN2Y+OJfnjNJFg4Dfdi2s+QzmqA@mail.gmail.com
* Re-allow planner to use Merge Append to efficiently implement UNION.Robert Haas2024-05-21
| | | | | | | | | | | This reverts commit 7204f35919b7e021e8d1bc9f2d76fd6bfcdd2070, thus restoring 66c0185a3 (Allow planner to use Merge Append to efficiently implement UNION) as well as the follow-on commits d5d2205c8, 3b1a7eb28, 7487044d6. Per further discussion on pgsql-release, we wish to ship beta1 with this feature, and patch the bug that was found just before wrap, rather than shipping beta1 with the feature reverted.
* Revert commit 66c0185a3 and follow-on patches.Tom Lane2024-05-20
| | | | | | | | | | | | | | | | | | | This reverts 66c0185a3 (Allow planner to use Merge Append to efficiently implement UNION) as well as the follow-on commits d5d2205c8, 3b1a7eb28, 7487044d6. In addition to those, 07746a8ef had to be removed then re-applied in a different place, because 66c0185a3 moved the relevant code. The reason for this last-minute thrashing is that depesz found a case in which the patched code creates a completely wrong plan that silently gives incorrect query results. It's unclear what the cause is or how many cases are affected, but with beta1 wrap staring us in the face, there's no time for closer investigation. After we figure that out, we can decide whether to un-revert this for beta2 or hold it for v18. Discussion: https://postgr.es/m/Zktzf926vslR35Fv@depesz.com (also some private discussion among pgsql-release)
* Translation updatesPeter Eisentraut2024-05-20
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 647792ce18e56f51614f7559106ad15362c5d1cc
* Add test case showing that commit d0d44049d fixed a live bug.Tom Lane2024-05-18
| | | | | | | | | | | | | | When I committed d0d44049d (Account for optimized MinMax aggregates during SS_finalize_plan), I didn't have a test case showing that it was fixing any reachable bug. Here is one, based on bug #18465 from Hal Takahara. Without the fix, all rows of the result show the same "min" value, because the aggregate doesn't get recalculated. Committed despite beta1 release freeze, with the concurrence of pgsql-release. Discussion: https://postgr.es/m/18465-2fae927718976b22@postgresql.org Discussion: https://postgr.es/m/2391880.1689025003@sss.pgh.pa.us
* Sync typedefs.list with buildfarm, for real this time.Tom Lane2024-05-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit da256a4a7, I manually added some typedef names to the buildfarm-generated list so as not to cause any formatting regressions compared to the prior manually-updated list. About half of the additions were injection-point-related names. It turns out that those were missing because none of the buildfarm animals contributing typedef lists were building with --enable-injection-points. I rectified that on my animal sifaka, and now those are in the list available from the buildfarm. The other half were typedefs that didn't show up in the generated list because our method for collecting that doesn't catch names that are not used to declare any C variables or fields. Such a typedef name doesn't really add a lot of value, so we decided to get rid of them, and that's now been done in commits 110eb4aef and be5942aee. (Note: I'm pretty sure there are some remaining cases of that, but we've already accepted the ensuing odd formatting of the typedef declaration itself. The present fixes only dealt with typedefs that had been manually added to typedefs.list during the v17 development cycle.) Hence, we can now install a verbatim copy of the buildfarm's list and not have it affect anything. The only change is to add InjectionPointCallback, which I'd omitted from da256a4a7 because it chanced not to affect any pgindent decisions. Discussion: https://postgr.es/m/1919000.1715815925@sss.pgh.pa.us
* A few follow-up fixes for GUC name quotingPeter Eisentraut2024-05-17
| | | | | | Fixups for 17974ec259: Some messages were missed (and some were new since the patch was originally proposed), and there was a typo introduced.
* Revise GUC names quoting in messages againPeter Eisentraut2024-05-17
| | | | | | | | | | | | | | | After further review, we want to move in the direction of always quoting GUC names in error messages, rather than the previous (PG16) wildly mixed practice or the intermittent (mid-PG17) idea of doing this depending on how possibly confusing the GUC name is. This commit applies appropriate quotes to (almost?) all mentions of GUC names in error messages. It partially supersedes a243569bf65 and 8d9978a7176, which had moved things a bit in the opposite direction but which then were abandoned in a partial state. Author: Peter Smith <smithpb2250@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut%2BPv-kSN8SkxSdoHano_wPubqcg5789ejhCDZAcLFceBR-w%40mail.gmail.com
* Remove unused typedefsPeter Eisentraut2024-05-17
| | | | | | | | | | | | | | | | | | There were a few typedefs that were never used to define a variable or field. This had the effect that the buildfarm's typedefs.list would not include them, and so they would need to be re-added manually to keep the overall pgindent result perfectly clean. We can easily get rid of these typedefs to avoid the issue. In a few cases, we just let the enum or struct stand on its own without a typedef around it. In one case, an enum was abused to define flag bits; that's better done with macro definitions. This fixes all the remaining issues with missing entries in the buildfarm's typedefs.list. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/1919000.1715815925@sss.pgh.pa.us
* Remove enum WaitEventExtensionMichael Paquier2024-05-17
| | | | | | | | | | | | | | | | | | This enum was used to determine the first ID to use when assigning a custom wait event for extensions, which is always 1. It was kept so as it would be possible to add new in-core wait events in the category "Extension". There is no such thing currently, so let's remove this enum until a case justifying it pops up. This makes the code simpler and easier to understand. This has as effect to switch back autoprewarm.c to use PG_WAIT_EXTENSION rather than WAIT_EVENT_EXTENSION, on par with v16 and older stable branches. Thinko in c9af05465307. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/195c6c45-abce-4331-be6a-e87724e1d060@eisentraut.org
* Fix documentation about DROP DATABASE FORCE process termination rights.Noah Misch2024-05-16
| | | | | | | | | | | Specifically, it terminates a background worker even if the caller couldn't terminate the background worker with pg_terminate_backend(). Commit 3a9b18b3095366cd0c4305441d426d04572d88c1 neglected to update this. Back-patch to v13, which introduced DROP DATABASE FORCE. Reviewed by Amit Kapila. Reported by Kirill Reshke. Discussion: https://postgr.es/m/20240429212756.60.nmisch@google.com
* BitmapHeapScan: Remove incorrect assert and reset fieldMelanie Plageman2024-05-16
| | | | | | | | | | | | | | | | | | | | | | 04e72ed617be pushed the skip fetch optimization (allowing bitmap heap scans to operate like index-only scans if none of the underlying data is needed) into heap AM implementations of bitmap table scan callbacks. 04e72ed617be added an assert that all tuples in blocks eligible for the optimization had been NULL-filled and emitted by the end of the scan. This assert is incorrect when not all tuples need be scanned to execute the query; for example: a join in which not all inner tuples need to be scanned before skipping to the next outer tuple. Remove the assert and reset the field on which it previously asserted to avoid incorrectly emitting NULL-filled tuples from a previous scan on rescan. Author: Melanie Plageman Reviewed-by: Tomas Vondra, Michael Paquier, Alvaro Herrera Reported-by: Melanie Plageman Reproduced-by: Tomas Vondra, Richard Guo Discussion: https://postgr.es/m/CAMbWs48orzZVXa7-vP9Nt7vQWLTE04Qy4PePaLQYsVNQgo6qRg%40mail.gmail.com
* Remove option to fall back from direct to postgres SSL negotiationHeikki Linnakangas2024-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were three problems with the sslnegotiation options: 1. The sslmode=prefer and sslnegotiation=requiredirect combination was somewhat dangerous, as you might unintentionally fall back to plaintext authentication when connecting to a pre-v17 server. 2. There was an asymmetry between 'postgres' and 'direct' options. 'postgres' meant "try only traditional negotiation", while 'direct' meant "try direct first, and fall back to traditional negotiation if it fails". That was apparent only if you knew that the 'requiredirect' mode also exists. 3. The "require" word in 'requiredirect' suggests that it's somehow more strict or more secure, similar to sslmode. However, I don't consider direct SSL connections to be a security feature. To address these problems: - Only allow sslnegotiation='direct' if sslmode='require' or stronger. And for the record, Jacob and Robert felt that we should do that (or have sslnegotiation='direct' imply sslmode='require') anyway, regardless of the first issue. - Remove the 'direct' mode that falls back to traditional negotiation, and rename what was called 'requiredirect' to 'direct' instead. In other words, there is no "try both methods" option anymore, 'postgres' now means the traditional negotiation and 'direct' means a direct SSL connection. Reviewed-by: Jelte Fennema-Nio, Robert Haas, Jacob Champion Discussion: https://www.postgresql.org/message-id/d3b1608a-a1b6-4eda-9ec5-ddb3e4375808%40iki.fi
* pg_amcheck: Put new options in consistent order in --help and man pagePeter Eisentraut2024-05-16
|
* Revert temporal primary keys and foreign keysPeter Eisentraut2024-05-16
| | | | | | | | | | | | | | | | | | | | This feature set did not handle empty ranges correctly, and it's now too late for PostgreSQL 17 to fix it. The following commits are reverted: 6db4598fcb8 Add stratnum GiST support function 46a0cd4cefb Add temporal PRIMARY KEY and UNIQUE constraints 86232a49a43 Fix comment on gist_stratnum_btree 030e10ff1a3 Rename pg_constraint.conwithoutoverlaps to conperiod a88c800deb6 Use daterange and YMD in without_overlaps tests instead of tsrange. 5577a71fb0c Use half-open interval notation in without_overlaps tests 34768ee3616 Add temporal FOREIGN KEY contraints 482e108cd38 Add test for REPLICA IDENTITY with a temporal key c3db1f30cba doc: clarify PERIOD and WITHOUT OVERLAPS in CREATE TABLE 144c2ce0cc7 Fix ON CONFLICT DO NOTHING/UPDATE for temporal indexes Discussion: https://www.postgresql.org/message-id/d0b64a7a-dfe4-4b84-a906-c7dedfa40a3e@eisentraut.org
* Fix some inconsistencies in EXPLAIN outputDavid Rowley2024-05-16
| | | | | | | | | | | | | | | | | | | | | | | 06286709e added a SERIALIZE option to EXPLAIN which included showing the amount of kilobytes serialized. The calculation to convert bytes into kilobytes wasn't consistent with how that's done in the rest of EXPLAIN. Traditionally we round up to the nearest kB, but the new code rounded to the nearest kB. To fix this, invent a macro that does the conversion and use that macro everywhere that requires this conversion. Additionally, 5de890e36 added EXPLAIN (MEMORY) but included the memory sizes in bytes. Convert these values to kilobytes to align with the other memory related outputs. In passing, swap out a "long" type in show_hash_info() and use a uint64 instead. We do support platforms where sizeof(Size) == 8 and sizeof(long) == 4, so using a long there is questionable. Reported-by: jian he Reviewed-by: jian he Discussion: https://www.postgresql.org/message-id/CACJufxE4Sp7xvgOwhqtFx5hS85AxMKobPWDo-xZHZVTpK3EBjA@mail.gmail.com
* Doc: update src/tools/pgindent/README for current practice.Tom Lane2024-05-15
| | | | | | | | | | | This README explains how to run pgindent, but it was written for our former practice of running pgindent only infrequently. Nowadays the plan is to keep the tree indent-clean all the time, so the typical thing is to do an incremental pgindent run with each commit. Revise to explain that as the normal case, and the infrequent full-on process as a separate thing. For now, pgperltidy is still a run-it-infrequently item.
* Fix query result leak during binary upgradeDaniel Gustafsson2024-05-15
| | | | | | | | | | | | 9a974cbcba00 moved the query in binary_upgrade_set_pg_class_oids to the outer level, but left the PQclear and query buffer destruction in the is_index conditional. 353708e1fb2d fixed the leak of the query buffer but left the PGresult leak. This moves clearing the result to the outer level ensuring that it will be called. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/374550C1-F4ED-4D9D-9498-0FD029CCF674@yesql.se Backpatch-through: v15
* Re-forbid underscore in positional parametersPeter Eisentraut2024-05-15
| | | | | | | | | | | | | | | | Underscores were added to numeric literals in faff8f8e47. This change also affected the positional parameters (e.g., $1) rule, which uses the same production for its digits. But this did not actually work, because the digits for parameters are processed using atol(), which does not handle underscores and ignores whatever it cannot parse. The underscores notation is probably not useful for positional parameters, so for simplicity revert that rule to its old form that only accepts digits 0-9. Author: Erik Wienhold <ewie@ewie.name> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/5d216d1c-91f6-4cbe-95e2-b4cbd930520c%40ewie.name
* Remove stray blank line among gram.y keywordsPeter Eisentraut2024-05-15
| | | | introduced by de3600452b
* Make all Perl warnings fatal, catch-upPeter Eisentraut2024-05-15
| | | | Apply c5385929593 to new Perl files that had missed the note.
* Add missing newline at the end of index_including.sqlMichael Paquier2024-05-15
| | | | Thinko in a63224be49b8.
* Fix incorrect year in some copyright notices added this yearDavid Rowley2024-05-15
| | | | | | | A few patches that were written <= 2023 and committed in 2024 still contained 2023 copyright year. Fix that. Discussion: https://postgr.es/m/CAApHDvr5egyW3FmHbAg-Uq2p_Aizwco1Zjs6Vbq18KqN64-hRA@mail.gmail.com
* Fix handling of polymorphic output arguments for procedures.Tom Lane2024-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d8a2@postgresql.org
* Do pre-release housekeeping on catalog data.Tom Lane2024-05-14
| | | | | | | Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta tasks specified by RELEASE_CHANGES. For reference, the command was ./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6300
* Pre-beta mechanical code beautification.Tom Lane2024-05-14
| | | | | | | | | | | | | | Run pgindent, pgperltidy, and reformat-dat-files. The pgindent part of this is pretty small, consisting mainly of fixing up self-inflicted formatting damage from patches that hadn't bothered to add their new typedefs to typedefs.list. In order to keep it from making anything worse, I manually added a dozen or so typedefs that appeared in the existing typedefs.list but not in the buildfarm's list. Perhaps we should formalize that, or better find a way to get those typedefs into the automatic list. pgperltidy is as opinionated as always, and reformat-dat-files too.
* Add missing gettext triggersPeter Eisentraut2024-05-14
| | | | | | | | Commit d6607016c7 moved all the jsonapi.c error messages into token_error(). This needs to be added to the various nls.mk files that use this. Since that makes token_error() effectively a globally known symbol, the name seems a bit too general, so rename to json_token_error() for more clarity.
* Add missing source files to pg_combinebackup/nls.mkPeter Eisentraut2024-05-14
|
* Remove auth-options support from initdbDaniel Gustafsson2024-05-14
| | | | | | | | | | | | | | | | | | | | | | | When --auth was added to initdb in commit e7029b212755 it had support for auth options separated by space from the auth type, like: --auth pam <servicename> --auth ident sameuser Passing an option to the ident auth type was removed in 01c1a12a5bb4 which left the pam auth-options support in place. 8a02339e9ba3 broke this by inverting a calculation in the strncmp arguments, which went unnoticed for a long time. The ability to pass options to the auth type was never documented. Rather than fixing the support for an undocumented feature which has been broken for all supported versions, and which only supports one out of many auth types which can take options, it is removed. Reported-by: Jingxian Li <aqktjcm@qq.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Aleksander Alekseev <aleksander@timescale.com> Discussion: https://postgr.es/m/tencent_29731C7C7E6A2F9FB807C3A1DC3D81293C06@qq.com
* Fix memory leaks in error reporting with LOG levelDaniel Gustafsson2024-05-14
| | | | | | | | | | When loglevel is set to LOG, allocated strings used in the error message would leak. Fix by explicitly pfreeing them. Author: Ranier Vilela <ranier.vf@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/CAEudQAqMeE0AHcOsOzZx51Z0eiFJAjhBPRFt+Bxi3ETXWen7ig@mail.gmail.com
* Add missing gettext triggersPeter Eisentraut2024-05-14
| | | | | Due to commit dc212340058, which added use of src/common/parse_manifest.c in the backend.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-20 08:59:04 +0000