aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* libpq: Error message improvementAlvaro Herrera2023-05-16
| | | | | Move a variable name out of the translatable message, to make it identical to others.
* Mark internal messages as no longer translatableAlvaro Herrera2023-05-16
| | | | | | | | | | | The problem that these messages protect against can only occur because a corrupted hash spill file was written, i.e., a Postgres bug. There's no reason to have them as translatable. Backpatch to 15, where these messages were changed by commit c4649cce39a4. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/20230510175407.dwa5v477pw62ikyx@alvherre.pgsql
* Fix reported runtime for single tests in pg_regressDaniel Gustafsson2023-05-16
| | | | | | | | | Commit 558fff0adf got the order of the parameters to test_status_failed mixed up which resulted in the runtime being reported as 0 ms. Fix by changing the order to the correct one. No backpatching is needed since this has not been shipped in a release yet. Discussion: https://postgr.es/m/0134C9EC-5F6B-4EAC-B2D5-BB4249BEBD4D@yesql.se
* libpq: Error message improvementPeter Eisentraut2023-05-16
|
* psql: Adjust capitalization of table headingPeter Eisentraut2023-05-16
| | | | for consistency with surrounding headings
* Fix incorrect TAP test orderingPeter Eisentraut2023-05-15
| | | | | | | | | | | | Using a test function before a possible skip_all is incorrect. If the skip_all is called, the test output will become incorrect and the test file will fail. a4f23f9b3c introduced a new test before skip_all. After discussion, this doesn't really need to be a test. Instead, we just bail out if the condition is not satisfied. Discussion: https://www.postgresql.org/message-id/af5567a1-aea6-fbdb-7e4b-d1e23a43c43b@enterprisedb.com
* Fix whitespace inconsistenciesPeter Eisentraut2023-05-15
|
* Fix wal_writer_flush_after initializer value.Thomas Munro2023-05-15
| | | | | | | | | | Commit a73952b7956 (new in 16) required default values in guc_table.c and C variable initializers to match. This one only matched when XLOG_BLCKSZ == 8kB. Fix by using the same expression in both places with a new DEFAULT_XXX macro, as done for other GUCs. Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGLNmLV=VrT==5MqnbARgx2ifRSFtdd8ofdfrdSLL3yv5A@mail.gmail.com
* Rename io_direct to debug_io_direct.Thomas Munro2023-05-15
| | | | | | | | | | | | | | | | | | Give the new GUC introduced by d4e71df6 a name that is clearly not intended for mainstream use quite yet. Future proposals would drop the prefix only after adding infrastructure to make it efficient. Having the switch in the tree sooner is good because it might lead to new discoveries about the hazards awaiting us on a wide range of systems, but that name was too enticing and could lead to cross-version confusion in future, per complaints from Noah and Justin. Suggested-by: Noah Misch <noah@leadboat.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (the idea, not the patch) Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (ditto) Discussion: https://postgr.es/m/20230430041106.GA2268796%40rfd.leadboat.com
* Improve error message for pg_create_subscription.Nathan Bossart2023-05-12
| | | | | | | | c3afe8cf5a updated this error message, but it didn't use the new style established in de4d456b40. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/20230512203721.GA2644063%40nathanxps13.home
* Tighten usage of PSQL_WATCH_PAGER.Tom Lane2023-05-12
| | | | | | | | | | | | | | | | | | | | | | Don't use PSQL_WATCH_PAGER when stdin/stdout are not a terminal. This corresponds to the restrictions on when other commands will use [PSQL_]PAGER. There isn't a lot of sense in trying to use a pager in non-interactive cases, and doing so allows an environment setting to break our tests. Also, ignore PSQL_WATCH_PAGER if it is set but empty or all-blank, for the same reasons we ignore such settings of [PSQL_]PAGER (see commit 18f8f784c). No documentation change is really needed, since there is nothing suggesting that these constraints on [PSQL_]PAGER didn't already apply to PSQL_WATCH_PAGER too. But I rearranged the text a little to make it read more naturally (IMHO anyway). Per report from Pavel Stehule. Back-patch to v15 where PSQL_WATCH_PAGER was introduced. Discussion: https://postgr.es/m/CAFj8pRDTwFzmEWdA-gdAcUh0ZnxUioSfTMre71WyB_wNJy-8gw@mail.gmail.com
* initdb: Set collversion for standard collation UNICODEPeter Eisentraut2023-05-12
| | | | | | | | | | Since the behavior of the UNICODE collation can change with new ICU/Unicode versions, we need to apply the versioning mechanism to it. We do this with an UPDATE command in initdb; this is similar to how we put the collation version into pg_database already. Reported-by: Daniel Verite <daniel@manitou-mail.org> Discussion: https://www.postgresql.org/message-id/49417853-7bdd-4b23-a4e9-04c7aff33821@manitou-mail.org
* Undo faulty attempt at not relying on RINFO_IS_PUSHED_DOWN.Tom Lane2023-05-11
| | | | | | | | | | | | | | I've had a bee in my bonnet for some time about getting rid of RestrictInfo.is_pushed_down, because it's squishily defined and requires not-inexpensive extra tests to use (cf RINFO_IS_PUSHED_DOWN). In commit 2489d76c4, I tried to make remove_rel_from_query() not depend on that macro; but the replacement test is buggy, as exposed by a report from Rushabh Lathia and Robert Haas. That change was pretty incidental to the main goal of 2489d76c4, so let's just revert it for now. (Getting rid of is_pushed_down is still far away, anyway.) Discussion: https://postgr.es/m/CA+TgmoYco=hmg+iX1CW9Y1_CzNoSL81J03wUG-d2_3=rue+L2A@mail.gmail.com
* Fix publication syntax error messageAlvaro Herrera2023-05-10
| | | | | | | | | | | | There was some odd wording in corner-case gram.y error messages "some error ... at or near", which appears to have been modeled after "syntax error" messages. However, they don't work that way, and they're just wrong. They're also uncovered by tests. Remove the trailing words, and also add tests. They were introduced with 5a2832465fd8; backpatch to 15. Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
* Add missing gettext triggersPeter Eisentraut2023-05-10
| | | | due to the changes in commit dac048f71e
* Fix assertion failure when updating stats_fetch_consistency in a transactionMichael Paquier2023-05-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An update of the GUC stats_fetch_consistency in a transaction would be able to trigger an assertion when doing cache->snapshot. In this case, when retrieving a pgstat entry after the switch, a new snapshot would be rebuilt, confusing pgstat_build_snapshot() because a snapshot is already cached with an unexpected mode ("cache"). In order to fix this problem, this commit adds a flag to force a snapshot clear each time this GUC is changed. Some tests are added to check, while on it. Some optimizations in avoiding the snapshot clear should be possible depending on what is cached and the current GUC value, I guess, but this solution is simple, and ensures that the state of the cache is updated each time a new pgstat entry is fetched, hence being consistent with the level wanted by the client that has set the GUC. Note that cache->none and snapshot->none would not cause issues, as fetching a pgstat entry would be retrieved from shared memory on the second attempt, however a snapshot would still be cached. Similarly, none->snapshot and none->cache would build a new snapshot on the second fetch attempt. Finally, snapshot->cache would cache a new snapshot on the second attempt. Reported-by: Alexander Lakhin Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/17804-2a118cd046f2d0e5@postgresql.org backpatch-through: 15
* Document values of stats_fetch_consistency in postgresql.conf.sampleMichael Paquier2023-05-10
| | | | | | Issue noted while looking at a patch related to that. Discussion: https://postgr.es/m/ZE9LiFc7JdNHokz/@paquier.xyz
* Fix the race condition in the test case added by commit a6e04b1d20.Amit Kapila2023-05-09
| | | | | | | | | | | | | | | The commit a6e04b1d20 added a test to ensure that the invalidated logical slots don't retain WAL. The test was ensuring that the checkpoint removes the WAL files corresponding to invalidated logical slots on the standby node but missed the point that the standby node also had a physical slot which led to the prevention of WAL file removal. Move the creation of physical slot on the standby and initialization of cascading standby closer to the test case that actually required it so that other tests don't get affected by the presence of the physical slot on standby. Author: Bertrand Drouvot Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/2fefa454-5a70-2174-ddbf-4a0e41537139@gmail.com
* Fix invalid memory access during the shutdown of the parallel apply worker.Amit Kapila2023-05-09
| | | | | | | | | | | | | | | | | | | | | | | The callback function pa_shutdown() accesses MyLogicalRepWorker which may not be initialized if there is an error during the initialization of the parallel apply worker. The other problem is that by the time it is invoked even after the initialization of the worker, the MyLogicalRepWorker will be reset by another callback logicalrep_worker_onexit. So, it won't have the required information. To fix this, register the shutdown callback after we are attached to the worker slot. After this fix, we observed another issue which is that sometimes the leader apply worker tries to receive the message from the error queue that might already be detached by the parallel apply worker leading to an error. To prevent such an error, we ensure that the leader apply worker detaches from the parallel apply worker's error queue before stopping it. Reported-by: Sawada Masahiko Author: Hou Zhijie Reviewed-by: Sawada Masahiko, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDo+yUwNq6nTrvE2h9bB2vZfcag=jxWc7QxuWCmkDAqcA@mail.gmail.com
* Revert "ICU: do not convert locale 'C' to 'en-US-u-va-posix'."Jeff Davis2023-05-08
| | | | | | This reverts commit f7faa9976cc0504c027a20ed66ceca9018041dd4. Discussion: https://postgr.es/m/483826.1683582475@sss.pgh.pa.us
* ICU: do not convert locale 'C' to 'en-US-u-va-posix'.Jeff Davis2023-05-08
| | | | | | | | | | The conversion was intended to be for convenience, but it's more likely to be confusing than useful. The user can still directly specify 'en-US-u-va-posix' if desired. Discussion: https://postgr.es/m/f83f089ee1e9acd5dbbbf3353294d24e1f196e95.camel@j-davis.com Discussion: https://postgr.es/m/37520ec1ae9591f83132f82dbd625f3fc2d69c16.camel@j-davis.com
* Handle RLS dependencies in inlined set-returning functions properly.Tom Lane2023-05-08
| | | | | | | | | | | | | | | If an SRF in the FROM clause references a table having row-level security policies, and we inline that SRF into the calling query, we neglected to mark the plan as potentially dependent on which role is executing it. This could lead to later executions in the same session returning or hiding rows that should have been hidden or returned instead. Our thanks to Wolfgang Walther for reporting this problem. Stephen Frost and Tom Lane Security: CVE-2023-2455
* Replace last PushOverrideSearchPath() call with set_config_option().Noah Misch2023-05-08
| | | | | | | | | | | | | | | | | | | | | The two methods don't cooperate, so set_config_option("search_path", ...) has been ineffective under non-empty overrideStack. This defect enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. While that particular attack requires v13+ for the trusted extension attribute, other attacks are feasible in all supported versions. Standardize on the combination of NewGUCNestLevel() and set_config_option("search_path", ...). It is newer than PushOverrideSearchPath(), more-prevalent, and has no known disadvantages. The "override" mechanism remains for now, for compatibility with out-of-tree code. Users should update such code, which likely suffers from the same sort of vulnerability closed here. Back-patch to v11 (all supported versions). Alexander Lakhin. Reported by Alexander Lakhin. Security: CVE-2023-2454
* Add missing source file to nls.mkPeter Eisentraut2023-05-08
|
* pg_dump: Restore lost translation markerPeter Eisentraut2023-05-08
| | | | The refactoring in 03d02f54a6 lost a translation marker.
* pg_basebackup: Restore lost translation markersPeter Eisentraut2023-05-08
| | | | The refactoring in ebfb814f7c lost some translation markers.
* Add ruleutils support for decompiling MERGE commands.Tom Lane2023-05-07
| | | | | | | | | This was overlooked when MERGE was added, but it's essential support for MERGE in new-style SQL functions. Alvaro Herrera Discussion: https://postgr.es/m/3579737.1683293801@sss.pgh.pa.us
* Fix typo with wait event for SLRU buffer of commit timestampsMichael Paquier2023-05-05
| | | | | | | | | | | | | This wait event was documented as "CommitTsBuffer" since its introduction, but the code named it "CommitTSBuffer". This commit fixes the code to follow the term documented, which is also more consistent with the naming of the other wait events used for commit timestamps. Introduced by 5da1493. Author: Alexander Lakhin Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com Backpatch-through: 13
* Fix copy-and-pasto in error messagePeter Eisentraut2023-05-05
| | | | from 2fe3bdbd69
* Fix prove_installcheck when used with PGXSPeter Eisentraut2023-05-05
| | | | | | | | | | | | | | | | | | Commit 153e215677 added the portlock directory. This is created in $ENV{top_builddir} if it is set. Under PGXS, top_builddir points into the installation directory, which is not necessarily writable and in any case inappropriate to use by a test suite. The cause of the problem is that the prove_installcheck target in Makefile.global exports top_builddir, which isn't useful (since no other Perl code actually reads it) and breaks this use case. The reason this code is there is probably that is has been dragged around with various other changes, in particular a0fc813266, but without a real purpose of its own. By just removing the exporting of top_builddir in prove_installcheck, the portlock directory then ends up under tmp_check in the build directory, which is more suitable. Reviewed-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://www.postgresql.org/message-id/78d1cfa6-0065-865d-584b-cde6d8c18aff@enterprisedb.com
* Move return statements out of PG_TRY blocks.Nathan Bossart2023-05-04
| | | | | | | | | | | | | | | | | | If we exit a PG_TRY block early via "continue", "break", "goto", or "return", we'll skip unwinding its exception stack. This change moves a couple of such "return" statements in PL/Python out of PG_TRY blocks. This was introduced in d0aa965c0a and affects all supported versions. We might also be able to add compile-time checks to prevent recurrence, but that is left as a future exercise. Reported-by: Mikhail Gribkov, Xing Guo Author: Xing Guo Reviewed-by: Michael Paquier, Andres Freund, Tom Lane Discussion: https://postgr.es/m/CAMEv5_v5Y%2B-D%3DCO1%2Bqoe16sAmgC4sbbQjz%2BUtcHmB6zcgS%2B5Ew%40mail.gmail.com Discussion: https://postgr.es/m/CACpMh%2BCMsGMRKFzFMm3bYTzQmMU5nfEEoEDU2apJcc4hid36AQ%40mail.gmail.com Backpatch-through: 11 (all supported versions)
* Fix ExecCheckPermissions call in RI_Initial_CheckAlvaro Herrera2023-05-04
| | | | | | | | | | | | | | | | | | RI_Initial_Check was setting up a list of RTEPermissionInfo for ExecCheckPermissions() wrong, and the problem is subtle enough that it doesn't have any immediate effect in core code. However, if an extension is using the ExecutorCheckPerms_hook, then it would get the wrong parameters and perhaps arrive at a wrong conclusion, or outright malfunction. Fix by constructing that list and the RTE list more honestly. We also add an assertion check to verify that these lists match. This new assertion would have caught this bug. Co-authored-by: Олег Целебровский (Oleg Tselebrovskii) <o.tselebrovskiy@postgrespro.ru> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/3722b7a2cbe27a1796ee40824bd86dd1@postgrespro.ru
* In array_position()/array_positions(), beware of empty input array.Tom Lane2023-05-04
| | | | | | | | | | | | These functions incautiously fetched the array's first lower bound even when the array is zero-dimensional, thus fetching the word after the allocated array space. While almost always harmless, with very bad luck this could result in SIGSEGV. Fix by adding an early exit for empty input. Per bug #17920 from Alexander Lakhin. Discussion: https://postgr.es/m/17920-f7c228c627b6d02e%40postgresql.org
* Tighten array dimensionality checks in Python -> SQL array conversion.Tom Lane2023-05-04
| | | | | | | | | | | | | | | | | | | | | | Like plperl before f47004add, plpython wasn't being sufficiently careful about checking that list-of-list structures represent rectangular arrays, so that it would accept some cases in which different parts of the "array" are nested to different depths. This was exacerbated by Python's weak distinction between sequences and lists, so that in some cases strings could get treated as though they are lists (and burst into individual characters) even though a different ordering of the upper-level list would give a different result. Some of this behavior was unreachable (without risking a crash) before 81eaaf65e. It seems like a good idea to clean it all up in the same releases, rather than shipping a non-crashing but nonetheless visibly buggy behavior in the name of minimal change. Hence, back-patch. Per bug #17912 and further testing by Alexander Lakhin. Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org
* Revert "Move PartitionPruneInfo out of plan nodes into PlannedStmt"Alvaro Herrera2023-05-04
| | | | | | | | | | | | | This reverts commit ec386948948c and its fixup 589bb816499e. This change was intended to support query planning avoiding acquisition of locks on partitions that were going to be pruned; however, the overall project took a different direction at [1] and this bit is no longer needed. Put things back the way they were as agreed in [2], to avoid unnecessary complexity. Discussion: [1] https://postgr.es/m/4191508.1674157166@sss.pgh.pa.us Discussion: [2] https://postgr.es/m/20230502175409.kcoirxczpdha26wt@alvherre.pgsql
* Test that invalidated logical slots doesn't retain WAL.Amit Kapila2023-05-04
| | | | | | Author: Bertrand Drouvot Reviewed-by: Shi yu, Amit Kapila, Vignesh C Discussion: https://postgr.es/m/2fefa454-5a70-2174-ddbf-4a0e41537139@gmail.com
* Add missing TAP test namePeter Eisentraut2023-05-03
|
* Fix assertion failure in apply worker.Amit Kapila2023-05-03
| | | | | | | | | | | | | | During exit, the logical replication apply worker tries to release session level locks, if any. However, if the apply worker exits due to an error before its connection is initialized, trying to release locks can lead to assertion failure. The locks will be acquired once the worker is initialized, so we don't need to release them till the worker initialization is complete. Reported-by: Alexander Lakhin Author: Hou Zhijie based on inputs from Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/2185d65f-5aae-3efa-c48f-fb42b173ef5c@gmail.com
* Fix overridden callbacks in pg_rewind.Daniel Gustafsson2023-05-02
| | | | | | | | | | | | | The <source>_traverse_files functions take a callback for processing files, but both the local and libpq source implementations called the function directly without using the callback argument. While there is no bug right now as the function called is the same as the callback, fix by calling the callback to reduce the risk of subtle bugs in the future. Author: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Richard Guo <guofenglinux@gmail.com> Discussion: https://postgr.es/m/CAEG8a3Jdwgh+PZr2zh1=t8apA4Yz8tKq+uubPqoCt14nvWKHEw@mail.gmail.com
* Update SQL featuresPeter Eisentraut2023-05-02
| | | | Some updates for SQL:2023 and some new features in PostgreSQL 16.
* Add missing uninstallation rule for BackgroundPsql.pmPeter Eisentraut2023-05-02
| | | | | Commit a4c17c8617 added in the install rule but not the uninstall rule.
* Fix typos in commentsMichael Paquier2023-05-02
| | | | | | | | | The changes done in this commit impact comments with no direct user-visible changes, with fixes for incorrect function, variable or structure names. Author: Alexander Lakhin Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com
* Tighten array dimensionality checks in Perl -> SQL array conversion.Tom Lane2023-04-29
| | | | | | | | | | | | | | | | plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
* Handle zero-length sublist correctly in Python -> SQL array conversion.Tom Lane2023-04-28
| | | | | | | | | | | | | | | | | | | | If PLySequence_ToArray came across a zero-length sublist, it'd compute the overall array size as zero, possibly leading to a memory clobber. (This would likely qualify as a security bug, were it not that plpython is an untrusted language already.) I think there are other corner-case issues in this code as well, notably that the error messages don't match the core code and for some ranges of array sizes you'd get "invalid memory alloc request size" rather than the intended message about array size. Really this code has no business doing its own array size calculation at all, so remove the faulty code in favor of using ArrayGetNItems(). Per bug #17912 from Alexander Lakhin. Bug seems to have come in with commit 94aceed31, so back-patch to all supported branches. Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org
* Fix crashes with CREATE SCHEMA AUTHORIZATION and schema elementsMichael Paquier2023-04-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CREATE SCHEMA AUTHORIZATION with appended schema elements can lead to crashes when comparing the schema name of the query with the schemas used in the qualification of some clauses in the elements' queries. The origin of the problem is that the transformation routine for the elements listed in a CREATE SCHEMA query uses as new, expected, schema name the one listed in CreateSchemaStmt itself. However, depending on the query, CreateSchemaStmt.schemaname may be NULL, being computed instead from the role specification of the query given by the AUTHORIZATION clause, that could be either: - A user name string, with the new schema name being set to the same value as the role given. - Guessed from CURRENT_ROLE, SESSION_ROLE or CURRENT_ROLE, with a new schema name computed from the security context where CREATE SCHEMA is running. Regression tests are added for CREATE SCHEMA with some appended elements (some of them with schema qualifications), covering also some role specification patterns. While on it, this simplifies the context structure used during the transformation of the elements listed in a CREATE SCHEMA query by removing the fields for the role specification and the role type. They were not used, and for the role specification this could be confusing as the schema name may by extracted from that at the beginning of CreateSchemaCommand(). This issue exists for a long time, so backpatch down to all the versions supported. Reported-by: Song Hongyu Author: Michael Paquier Reviewed-by: Richard Guo Discussion: https://postgr.es/m/17909-f65c12dfc5f0451d@postgresql.org Backpatch-through: 11
* Fix assertion failure in heap_vacuum_relDaniel Gustafsson2023-04-28
| | | | | | | | | | | | | Commit 7d71d3dd08 changed resetting the VacuumFailsafeActive flag to an assertion since the flag is reset before starting vacuuming a relation. This however failed to take recursive calls of vacuum_rel() and vacuum of TOAST tables into consideration. Fix by reverting back to resettting the flag. Author: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Reported-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/CAFBsxsFz=GqaG5Ens5aNgVYoV2Y+pfMUijX0ku+CCkWfALwiqg@mail.gmail.com
* Add unit to vacuum_buffer_usage_limit value in postgresql.conf.sample.Masahiko Sawada2023-04-28
| | | | | | | | Also adjust the indentation of the comment to the surrounding parameters. Author: Masahiko Sawada Reviewed-by: David Rowley, Daniel Gustafsson, Melanie Plageman Discussion: https://postgr.es/m/CAD21AoCBSqmqOKVH4Q256DeCC_UE50gu1sgixcjLFZGLEbABVA@mail.gmail.com
* Improve one of the test cases in 035_standby_logical_decoding.pl.Amit Kapila2023-04-28
| | | | | | | | | | | | | | The test to ensure that decoding changes via logical slot from another database will fail was incorrectly done on the primary node instead of on the standby node. In the passing, make the test to wait for replay catchup by using wait_for_replay_catchup(). This will make it consistent with the way we wait at other places in the test. Author: Shi yu Reviewed-by: Bertrand Drouvot, Amit Kapila Discussion: https://postgr.es/m/OSZPR01MB6310B0A507A0F2A2D379F38CFD6A9@OSZPR01MB6310.jpnprd01.prod.outlook.com
* Prevent underflow in KeepLogSeg().Nathan Bossart2023-04-27
| | | | | | | | | | | | | | | The call to XLogGetReplicationSlotMinimumLSN() might return a greater LSN than the one given to the function. Subsequent segment number calculations might then underflow, which could result in unexpected behavior when removing or recyling WAL files. This was introduced with max_slot_wal_keep_size in c655077639. To fix, skip the block of code for replication slots if the LSN is greater. Reported-by: Xu Xingwang Author: Kyotaro Horiguchi Reviewed-by: Junwang Zhao Discussion: https://postgr.es/m/17903-4288d439dee856c6%40postgresql.org Backpatch-through: 13
* Fix wrong construct_array_builtin() call in GUCArrayDelete()Alexander Korotkov2023-04-27
| | | | | | | | | | The current code unintentionally uses the wrong datum to construct an array. The bug was introduced by 096dd80f3c, so no backpatching is needed. Reported-by: David Steele Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net Author: Nathan Bossart Reviewed-by: David Steele, Tom Lane