aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Fix an assert in CheckPointReplicationSlots().Amit Kapila2024-06-11
| | | | | | | | | | | | | | | | | | Commit e0b2eed047 assumed that the confirmed_flush LSN can't go backward. However, it is possible that confirmed_flush LSN can go backward temporarily when the client acknowledges a prior value of flush location. This can happen when the client (subscriber in this case) acknowledges an LSN it doesn't have to do anything for (say for DDLs) and thus didn't store persistently. After restart, the client sends the prior value of flush LSN which it had stored persistently and the server updates the confirmed_flush LSN with that value. The fix is to remove the assumption and not allow the prior value of confirmed_flush LSN to be flushed to the disk. Author: Vignesh C Reviewed-by: Amit Kapila, Shlok Kyal Discussion: https://postgr.es/m/CALDaNm3hgow2+oEov5jBk4iYP5eQrUCF1yZtW7+dV3J__p4KLQ@mail.gmail.com
* Doc: Fix ambuiguity in column lists.Amit Kapila2024-06-11
| | | | | | | | | | | The behavior for columns added later to the table for publications with no specified column lists was not clear. Reported-by: Koen De Groote Author: Peter Smith Reviewed-by: Vignesh C, Laurenz Albe Backpatch-through: 15 Discussion: https://postgr.es/m/171621878740.686.11325940592820985181@wrigleys.postgresql.org
* doc: Mention all options equivalent to pg_dump --filter patterns.Dean Rasheed2024-06-10
| | | | | | | | | | In the documentation for pg_dump's new --filter option, added by commit a5cf808be5, each object pattern should match some other existing pg_dump option, but some had been omitted, so add them. Noted by Daniel Gustafsson, reviewed by Ayush Vatsa. Discussion: https://postgr.es/m/CAEZATCWtVUt51B6BjTUQoS4dcNyOBj%2B04ngL7HSH3ehBXTUt%3Dw%40mail.gmail.com
* Fix comment about cross-checking the varnullingrelsRichard Guo2024-06-10
| | | | | | | | | The nullingrels match checks are not limited to debugging builds. Oversight in commit 867be9c07. Author: Richard Guo Reviewed-by: Alvaro Herrera, Tom Lane, Robert Haas Discussion: https://postgr.es/m/CAMbWs4_SDsdYD7DdQw7RXc3jv3axbg+RGZ7aSi9GaqX=F8hNVw@mail.gmail.com
* Fix RBM_ZERO_AND_LOCK.Thomas Munro2024-06-10
| | | | | | | | | | | | | | | | | | | | Commit 210622c6 accidentally zeroed out pages even if they were found in the buffer pool. It should always lock the page, but it should only zero pages that were not already valid. Otherwise, concurrent readers that hold only a pin could see corrupted page contents changing under their feet. While here, rename ZeroAndLockBuffer() to match the RBM_ flag name. Also restore a some useful comments lost by 210622c6's refactoring, and add some new ones to clarify why we need to use the BM_IO_IN_PROGRESS infrastructure despite not doing I/O. Reported-by: Noah Misch <noah@leadboat.com> Reported-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> (earlier version) Reviewed-by: Robert Haas <robertmhaas@gmail.com> (earlier version) Discussion: https://postgr.es/m/20240512171658.7e.nmisch@google.com Discussion: https://postgr.es/m/7ed10231-ce47-03d5-d3f9-4aea0dc7d5a4%40gmail.com
* Tighten test_predtest's input checks, and improve error messages.Tom Lane2024-06-07
| | | | | | | | | | | | | | | | | test_predtest() neglected to consider the possibility that SPI_plan_get_cached_plan would return NULL. This led to a core dump if the input (incorrectly) contains more than one SQL command. While here, let's expend more than zero effort on the error message for this case and nearby ones. Per (half of) bug #18483 from Alexander Kozhemyakin. Back-patch to all supported branches, not because this is very significant (it's merely test scaffolding) but to make our world a bit safer for fuzz testing. Discussion: https://postgr.es/m/18483-30bfff42de238000@postgresql.org
* Reject modifying a temp table of another session with ALTER TABLE.Tom Lane2024-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | Normally this case isn't even reachable by non-superusers, since permissions checks prevent naming such a table. However, it is possible to make it happen by altering a parent table whose child is another session's temp table. We definitely can't support any such ALTER that requires modifying the contents of such a table, since we lack access to the other session's temporary-buffer pool. But there seems no good reason to allow it even if it'd only require changing catalog contents. One reason not to allow it is that we'd rather not expose the implementation-dependent behavior of whether a specific ALTER requires touching the table contents. Another is that there may be (in future, even if not today) optimizations that assume that a session's own temp tables won't be modified by other sessions. Hence, add a RELATION_IS_OTHER_TEMP() check to all the places where ALTER TABLE currently does CheckTableNotInUse(). (I looked through all other callers of CheckTableNotInUse(), and they seem OK already.) Per bug #18492 from Alexander Lakhin. Back-patch to all supported branches. Discussion: https://postgr.es/m/18492-c7a2634bf4968763@postgresql.org
* Fix behavior of stable functions called from a CALL's argument list.Tom Lane2024-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | If the CALL is within an atomic context (e.g. there's an outer transaction block), _SPI_execute_plan should acquire a fresh snapshot to execute any such functions with. We failed to do that and instead passed them the Portal snapshot, which had been acquired at the start of the current SQL command. This'd lead to seeing stale values of rows modified since the start of the command. This is arguably a bug in 84f5c2908: I failed to see that "are we in non-atomic mode" needs to be defined the same way as it is further down in _SPI_execute_plan, i.e. check !_SPI_current->atomic not just options->allow_nonatomic. Alternatively the blame could be laid on plpgsql, which is unconditionally passing allow_nonatomic = true for CALL/DO even when it knows it's in an atomic context. However, fixing it in spi.c seems like a better idea since that will also fix the problem for any extensions that may have copied plpgsql's coding pattern. While here, update an obsolete comment about _SPI_execute_plan's snapshot management. Per report from Victor Yegorov. Back-patch to all supported versions. Discussion: https://postgr.es/m/CAGnEboiRe+fG2QxuBO2390F7P8e2MQ6UyBjZSL_w1Cej+E4=Vw@mail.gmail.com
* Add more debugging information when dropping twice pgstats entryMichael Paquier2024-06-07
| | | | | | | | | | | | | | | | | | | Floris Van Nee has reported a bug in the pgstats facility where a stats entry already dropped would get again dropped. This case should not happen, still the error generated did not offer any details about the stats entry getting dropped. This commit improves the error message generated to inform about the stats entry kind, database OID, object OID and refcount, which should help to debug more the problem reported. Bertrand Drouvot has been independently able to reach this error path while writing a new feature, and more details about the failure would have been helpful for debugging. Author: Andres Freund, Bertrand Drouvot Discussion: https://postgr.es/m/20240505160915.6boysum4f34siqct@awork3.anarazel.de Discussion: https://postgr.es/m/ZkM30paAD8Cr/Bix@ip-10-97-1-34.eu-west-3.compute.internal Backpatch-through: 15
* postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote servers.Etsuro Fujita2024-06-07
| | | | | | | | | | | | | | | | | | | | | Previously, when considering LIMIT pushdown, postgres_fdw failed to check whether the query has this clause, which led to pushing false LIMIT clauses, causing incorrect results. This clause has been supported since v13, so we need to do a remote-version check before deciding that it will be safe to push such a clause, but we do not currently have a way to do the check (without accessing the remote server); disable pushing such a clause for now. Oversight in commit 357889eb1. Back-patch to v13, where that commit added the support. Per bug #18467 from Onder Kalaci. Patch by Japin Li, per a suggestion from Tom Lane, with some changes to the comments by me. Review by Onder Kalaci, Alvaro Herrera, and me. Discussion: https://postgr.es/m/18467-7bb89084ff03a08d%40postgresql.org
* meson: Restore implicit warning/debug/optimize flags for extensionsPeter Eisentraut2024-06-07
| | | | | | | | | | | | | | | | | Meson uses warning/debug/optimize flags such as "-Wall", "-g", and "-O2" automatically based on "--warnlevel" and "--buildtype" options. And we use "--warning_level=1" and "--buildtype=debugoptimized" by default. But we need these flags for Makefile.global (for extensions) and pg_config, so we need to compute them manually based on the higher-level options. Without this change, extensions building using pgxs wouldn't get -Wall or optimization options. Author: Sutou Kouhei <kou@clear-code.com> Discussion: https://www.postgresql.org/message-id/flat/20240122.141139.931086145628347157.kou%40clear-code.com
* Doc: Add the new section "Logical Replication Failover".Amit Kapila2024-06-07
| | | | | | | | | | This aids the users to ensure that the failover marked slots are synced to the standby and subscribers can continue replication even when the publisher node goes down. Author: Hou Zhijie, Shveta Malik, Amit Kapila Reviewed-by: Peter Smith, Bertrand Drouvot Discussion: https://postgr.es/m/OS0PR01MB57164D6F53FB4F6AD29AD9C594FB2@OS0PR01MB5716.jpnprd01.prod.outlook.com
* doc: Fix copy-and-paste mistakePeter Eisentraut2024-06-07
| | | | | The wording from the "columns" view was copied to the "attributes" view without the required adjustments.
* Collation documentation fixes.Jeff Davis2024-06-06
| | | | Discussion: https://postgr.es/m/9beecdf7-e8c8-4eab-adc7-fa225c2feefd@eisentraut.org
* meson: Add user-provided c_args to bitcode_cflagsPeter Eisentraut2024-06-06
| | | | | | | This is needed for example to pass an include path set in the CPPFLAGS environment variable to the bitcode compile command. Discussion: https://www.postgresql.org/message-id/flat/c1384a7b-ed12-4862-a0da-a05c7945171a%40eisentraut.org
* Add meson NLS support for pg_walsummaryPeter Eisentraut2024-06-06
|
* Fix failure with SQL-procedure polymorphic output arguments in v12.Tom Lane2024-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions returning RECORD, but it doesn't happen in CALL, potentially resulting in crashes if the actual output of the SQL procedure's SELECT doesn't match the type inferred from polymorphism. With a little bit of rearrangement, we can use get_call_result_type instead of get_func_result_type and thereby infer the correct types. I'm still unwilling to back-patch all of 913bbd88d, so if the types don't match you'll get an error rather than perhaps silently inserting a cast as v13 and later can. That's consistent with prior behavior though, so it seems fine. Prior to 70ffb27b2, you'd typically get other errors due to other shortcomings of CALL's management of polymorphism. Nonetheless, this is an independent bug. Although there is no bug in v13 and up, it seems prudent to add the test case for this to the newer branches too. It's clearly an under-tested area. Per report from Andrew Bille. Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com
* Make RelationFlushRelation() work without ResourceOwner during abortHeikki Linnakangas2024-06-06
| | | | | | | | | | | | | | | | | | | | | ReorderBufferImmediateInvalidation() executes invalidation messages in an aborted transaction. However, RelationFlushRelation sometimes required a valid resource owner, to temporarily increment the refcount of the relache entry. Commit b8bff07daa worked around that in the main subtransaction abort function, AbortSubTransaction(), but missed this similar case in ReorderBufferImmediateInvalidation(). To fix, introduce a separate function to invalidate a relcache entry. It does the same thing as RelationClearRelation(rebuild==true) does when outside a transaction, but can be called without incrementing the refcount. Add regression test. Before this fix, it failed with: ERROR: ResourceOwnerEnlarge called after release started Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://www.postgresql.org/message-id/e56be7d9-14b1-664d-0bfc-00ce9772721c@gmail.com
* Restore preprocess_groupclause()Alexander Korotkov2024-06-06
| | | | | | | | | | | | | | | | | | | | | | | | 0452b461bc made optimizer explore alternative orderings of group-by pathkeys. It eliminated preprocess_groupclause(), which was intended to match items between GROUP BY and ORDER BY. Instead, get_useful_group_keys_orderings() function generates orderings of GROUP BY elements at the time of grouping paths generation. The get_useful_group_keys_orderings() function takes into account 3 orderings of GROUP BY pathkeys and clauses: original order as written in GROUP BY, matching ORDER BY clauses as much as possible, and matching the input path as much as possible. Given that even before 0452b461b, preprocess_groupclause() could change the original order of GROUP BY clauses we don't need to consider it apart from ordering matching ORDER BY clauses. This commit restores preprocess_groupclause() to provide an ordering of GROUP BY elements matching ORDER BY before generation of paths. The new version of preprocess_groupclause() takes into account an incremental sort. The get_useful_group_keys_orderings() function now takes into 2 orderings of GROUP BY elements: the order generated preprocess_groupclause() and the order matching the input path as much as possible. Discussion: https://postgr.es/m/CAPpHfdvyWLMGwvxaf%3D7KAp-z-4mxbSH8ti2f6mNOQv5metZFzg%40mail.gmail.com Author: Alexander Korotkov Reviewed-by: Andrei Lepikhov, Pavel Borisov
* Rename PathKeyInfo to GroupByOrderingAlexander Korotkov2024-06-06
| | | | | | | | | | | | | 0452b461bc made optimizer explore alternative orderings of group-by pathkeys. The PathKeyInfo data structure was used to store the particular ordering of group-by pathkeys and corresponding clauses. It turns out that PathKeyInfo is not the best name for that purpose. This commit renames this data structure to GroupByOrdering, and revises its comment. Discussion: https://postgr.es/m/db0fc3a4-966c-4cec-a136-94024d39212d%40postgrespro.ru Reported-by: Tom Lane Author: Andrei Lepikhov Reviewed-by: Alexander Korotkov, Pavel Borisov
* Add invariants check to get_useful_group_keys_orderings()Alexander Korotkov2024-06-06
| | | | | | | | | | This commit introduces invariants checking of generated orderings in get_useful_group_keys_orderings() for assert-enabled builds. Discussion: https://postgr.es/m/a663f0f6-cbf6-49aa-af2e-234dc6768a07%40postgrespro.ru Reported-by: Tom Lane Author: Andrei Lepikhov Reviewed-by: Alexander Korotkov, Pavel Borisov
* Fix asymmetry in setting EquivalenceClass.ec_sortrefAlexander Korotkov2024-06-06
| | | | | | | | | | | | | | | | | | 0452b461bc made get_eclass_for_sort_expr() always set EquivalenceClass.ec_sortref if it's not done yet. This leads to an asymmetric situation when whoever first looks for the EquivalenceClass sets the ec_sortref. It is also counterintuitive that get_eclass_for_sort_expr() performs modification of data structures. This commit makes make_pathkeys_for_sortclauses_extended() responsible for setting EquivalenceClass.ec_sortref. Now we set the EquivalenceClass.ec_sortref's needed to explore alternative GROUP BY ordering specifically during building pathkeys by the list of grouping clauses. Discussion: https://postgr.es/m/17037754-f187-4138-8285-0e2bfebd0dea%40postgrespro.ru Reported-by: Tom Lane Author: Andrei Lepikhov Reviewed-by: Alexander Korotkov, Pavel Borisov
* doc PG 17 relnotes: adjust integer bin/oct funcs and psql tabBruce Momjian2024-06-05
| | | | | | | | Reported-by: Dean Rasheed Discussion: https://postgr.es/m/CAEZATCXiNyExAXxKCO1h6oBB2nbfq9PtdA1nQowRsVFW1eD_MQ@mail.gmail.com Backpatch-through: master
* Prevent inconsistent use of stats entry for replication slotsMichael Paquier2024-06-06
| | | | | | | | | | | | | | | | | | | | | | Concurrent activity around replication slot creation and drop could cause a replication slot to use a stats entry it should not have used when created, triggering an assertion failure when retrieving an inconsistent entry from the dshash table used by the stats facility. The issue is that pgstat_drop_replslot() calls pgstat_drop_entry() without checking the result. If pgstat_drop_entry() cannot free the entry related to the object dropped, pgstat_request_entry_refs_gc() should be called. AtEOXact_PgStat_DroppedStats() and surrounding routines dropping stats entries already do that. This is documented in pgstat_internal.h, but let's add a comment at the top of pgstat_drop_entry() as that can be easy to miss. Reported-by: Alexander Lakhin Author: Floris Van Nee Analyzed-by: Andres Freund Discussion: https://postgr.es/m/17947-b9554521ad963c9c@postgresql.org Backpatch-through: 15
* Fix documentation for POSIX semaphores.Nathan Bossart2024-06-05
| | | | | | | | | | The documentation for POSIX semaphores is missing a reference to max_wal_senders. This commit fixes that in the same way that commit 4ebe51a5fb fixed the same issue in the documentation for System V semaphores. Discussion: https://postgr.es/m/20240517164452.GA1914161%40nathanxps13 Backpatch-through: 12
* Move new SLRU buffers GUCs to a better place in postgresql.conf.samplePeter Eisentraut2024-06-05
| | | | | | They were under "File Locations", which doesn't make sense. Move them to Resource Usage / Memory, which matches their categorization in the source code and in the documentation.
* doc: Fix example with database regexp in HBA documentationMichael Paquier2024-06-05
| | | | | | | | | | | | | This HBA entry was using "local" while specifying an address, which was incorrect. While in it, this adjusts the format of the entry to be aligned with the surroundings. Oversight in 8fea86830e1d. Reported-by: Stéphane Schildknecht Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/44662001-54c4-4bfd-be93-35e01ca25fa1@gmail.com Backpatch-through: 16
* 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
* ci: windows: Use the same image for VS and MinGW tasksAndres Freund2024-06-03
| | | | | | | | | | The VS and MinGW Windows images have been merged, to reduce the space needed for images. Before 98811323c8e the split helped boot performance, but now that we are using VMs that doesn't appear to be the case anymore. Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/CAN55FZ2kWYjPd7uUC5QswrB3tfVJDiURqC%2BMGM6a3oeev%3DVgOA%40mail.gmail.com Backpatch: 15-, where CI was added
* 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 documentation for System V semaphores.Nathan Bossart2024-06-03
| | | | | | | | | | | | | | | | The formulas for SEMMNI and SEMMNS do not include the archiver process, which was converted to an auxiliary process in v14, and the WAL summarizer process, which was introduced in v17. This commit corrects these formulas and adds a missing reference to max_wal_senders nearby. Since this section of the documentation tends to be incorrect quite often, we should likely give up on documenting the exact formulas in favor of something less fragile, but that is left as a future exercise. Reported-by: Sami Imseih Reviewed-by: Sami Imseih Discussion: https://postgr.es/m/20240517164452.GA1914161%40nathanxps13 Backpatch-through: 12
* doc PG 17 relnotes: adjust IN wordingBruce Momjian2024-05-28
| | | | | | | | Reported-by: David Rowley Discussion: https://postgr.es/m/CAApHDvqmW0wQRam4paRbHvLQA+w5CJOCno4BCu=NFRLRhYhtRw@mail.gmail.com Backpatch-through: master
* 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 meson uuid header check so it works with MSVCAndrew Dunstan2024-05-26
| | | | | | The OSSP uuid.h file includes unistd.h, so to use it with MSVC we need to include the postgres include directories so it picks up our version of that in src/include/port/win32_msvc. Adjust the meson test accordingly.
* 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
* amcheck: Fixes for right page check during unique constraint checkAlexander Korotkov2024-05-26
| | | | | | | | | * Don't forget to pfree() the right page when it's to be ignored. * Report error on unexpected non-leaf right page even if this page is not to be ignored. This restores the logic which was unintendedly changed in 97e5b0026f. Reported-by: Pavel Borisov
* doc PG 17 relnotes: improve btree "set/array" matching itemBruce Momjian2024-05-25
| | | | | | | | Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-WznwSs5irUka2deUooSdH7Sts2oPdVv4PCOwhK51fq2ZTg@mail.gmail.com Backpatch-through: master
* doc PG 17 relnotes: fix "pg_stat_slru_reset" wordingBruce Momjian2024-05-25
| | | | | | | | Reported-by: Marcos Pegoraro Discussion: https://postgr.es/m/CAB-JLwYXrL-8FBfVDX8tevyTJ8y1SMmot5A-5cLqXAAne7W0CQ@mail.gmail.com Backpatch-through: master
* doc PG 17 relnote: adjust "SLRU cache sizes to be configured"Bruce Momjian2024-05-25
| | | | | | | | | | | | Add Álvaro Herrera as additional item author. Reported-by: Álvaro Herrera Discussion: https://postgr.es/m/202405231122.zew2gncy63fo@alvherre.pgsql Author: Álvaro Herrera Backpatch-through: master
* 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
* doc PG 17 relnotes: combine itemsBruce Momjian2024-05-25
| | | | | | | | Reported-by: Andres Freund Discussion: https://postgr.es/m/20240524182329.gmzcd3a2zrvyepgy@awork3.anarazel.de Backpatch-through: master
* 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.
* doc: Clean up title case usePeter Eisentraut2024-05-23
|
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-02 23:02:08 +0000