Merge up to pg16 branch point #89
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 a0fc813, 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 <[email protected]>
Discussion: https://www.postgresql.org/message-id/[email protected]
(cherry picked from commit 5d42a97519581a31bdc1d3d4cf10c07ae18b8296)
from 2fe3bdbd69 (cherry picked from commit b1c4ed2f02b0c4cf1942e6eb2995bdbf8db5cccf)
Commit f75cec4fff87 changed the order in which the relations are permission-checked in RI_Initial_Check, which the sepgsql test is sensitive to. Adapt. Discussion: https://postgr.es/m/[email protected] (cherry picked from commit 95f5a7a42c048ec01ba2650496296fe88aacd50f)
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/[email protected] Backpatch-through: 13 (cherry picked from commit 58f5edf849900bc248b7c909ca17da7287306c41)
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/[email protected] (cherry picked from commit 41e2c52fd6ebed6eff4184f68048813cc8886ec1)
The refactoring in ebfb814f7c lost some translation markers. (cherry picked from commit 90f0d2881445a266038d349073e571f06def656b)
Author: Peter Smith Reviewed-by: David Zhang Discussion: https://postgr.es/m/CAHut+Pst11ac2hcmePt1=oTmBwTT=DAssRR1nsdoy4BT+68=Mg@mail.gmail.com (cherry picked from commit 0890f7d528c45bcfef7d3edd5618e121f0357250)
The refactoring in 03d02f54a6 lost a translation marker. (cherry picked from commit 9f9abfeb10026bc2c2ac7076c6adff201608eab5)
(cherry picked from commit b8c3f6df85e78e09c9709fc895aced719aebd7f9)
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
(cherry picked from commit 681d9e4621aac0a9c71364b6f54f00f6d8c4337f)
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 (cherry picked from commit ca73753b090c33bc69ce299b4d7fff891a77b8ad)
Security: CVE-2023-2454 (cherry picked from commit 8d525d7b9545884a3e0d79adcd61543f9ae2ae28)
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/[email protected] Discussion: https://postgr.es/m/[email protected] (cherry picked from commit f7faa9976cc0504c027a20ed66ceca9018041dd4)
Commit 1de58df4, which added page-level freezing, taught VACUUM to reuse each page's "set-visibility-map" snapshotConflictHorizon for freezing (at least in the vast majority of cases where freezing went ahead). This made VACUUM FREEZE much less prone to generating recovery conflicts on standbys; VACUUM FREEZE became only slightly more likely to cause recovery conflicts than an equivalent VACUUM. Update old documentation that specifically warned of the likelihood of recovery conflicts from VACUUM FREEZE. Explain the same general issue (the issue of VACUUM generating recovery conflicts even in the absence of dead row cleanup) using the example of conflicts caused by VISIBLE WAL records. (cherry picked from commit 5698f07947396e1a7cd6564390306aafa26fc189)
This reverts commit f7faa9976cc0504c027a20ed66ceca9018041dd4. Discussion: https://postgr.es/m/[email protected] (cherry picked from commit 455f948b0d03a556533a7e4a1a8abf45f0eb202e)
…orker. 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 (cherry picked from commit 3d144c6c86025272e1711539f5fafb6fb85c4feb)
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/[email protected] (cherry picked from commit c5b7f67fcc8c4a01c82660eb0996a3c697fac283)
Issue noted while looking at a patch related to that. Discussion: https://postgr.es/m/ZE9LiFc7JdNHokz/@paquier.xyz (cherry picked from commit 4d47eff99cc08255f0ae3cc27dc24cc9b30a32e7)
…saction
BABELFISH-CONFLICT: see Postgres community repo for original commit
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/[email protected]
backpatch-through: 15
(cherry picked from commit 605994651b6a4209b418cb09d3c223ca269f7cfc)
due to the changes in commit dac048f71e (cherry picked from commit d8bcce1b5e99d8f6f12cb7a94190fdc5622355af)
Fix a link from the "Heap-Only Tuples" documentation section. Previously, its "fillfactor" link pointed to the "CREATE TABLE" command's documentation. Now the link directly points to the fillfactor storage parameter documentation (which is about half way into the "CREATE TABLE" sect1). Oversight in commit 115464bb. Backpatch: 12-, the first version with a usable reloption link. (cherry picked from commit 375407f4940ba0922513666f00852c54943eb1a0)
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 (cherry picked from commit c8b881d21fd8e0214bc43280d6231cc2c6ef55ef)
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 <[email protected]> Discussion: https://www.postgresql.org/message-id/[email protected] (cherry picked from commit e32701b8d285cd402f75fc9059d083e89ee8166b)
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 18f8f78). 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 (cherry picked from commit 51b2c08798867cb9788090704b37c4698b456240)
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 (cherry picked from commit 4d5105a684ba20bf6a98e6ae48224fe93382c040)
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 <[email protected]> Reviewed-by: Noah Misch <[email protected]> Reviewed-by: Justin Pryzby <[email protected]> (the idea, not the patch) Reviewed-by: Tom Lane <[email protected]> (ditto) Discussion: https://postgr.es/m/20230430041106.GA2268796%40rfd.leadboat.com (cherry picked from commit 319bae9a8da66678d80d862440e54cebc7b1cc24)
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 <[email protected]> Discussion: https://postgr.es/m/CA+hUKGLNmLV=VrT==5MqnbARgx2ifRSFtdd8ofdfrdSLL3yv5A@mail.gmail.com (cherry picked from commit 63932a6d38e5dfa6df2a51a04b7314ec1e4d3de7)
(cherry picked from commit 1d70fb400c2c8312dac3ff19a1bb1cb5351047ce)
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/[email protected] (cherry picked from commit 92155e15d3cfe97758552484acb1583aaf71cda6)
References to SDK 8.1a should have been cleaned up in 495ed0e, as only version 10 and above are supported with Windows 10 and newer versions. Reported-by: Thomas Munro Discussion: https://postgr.es/m/CA+hUKG++qE9uVjQaTTD7oaC8a2T3h8K50=Eqyx9uUZvOHa__ww@mail.gmail.com (cherry picked from commit 08c45ae235660844167de8730da908d351f4352d)
Author: Japin Li Discussion: https://www.postgresql.org/message-id/MEYP282MB16696317B5DA7D0D92306149B627A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM (cherry picked from commit 876d17d62fe84d706058f2458f067f0e9049a230)
Since 3db72eb, the query ID of utilities is generated using the Query structure, making the use of the query string in JumbleQuery() unnecessary. This commit removes the argument "querytext" from JumbleQuery(). Reported-by: Joe Conway Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/[email protected] (cherry picked from commit 2ecbb0a49359759b46dd82df4ac3a083c36b1db4)
…CH PARTITION A portion of ALTER TABLE .. ATTACH PARTITION is to ensure that the partition being attached to the partitioned table has a correct set of indexes, so as there is a consistent index mapping between the partitioned table and its new-to-be partition. However, as introduced in 8b08f7d, the current logic could choose an invalid index as a match, which is something that can exist when dealing with more than two levels of partitioning, like attaching a partitioned table (that has partitions, with an index created by CREATE INDEX ON ONLY) to another partitioned table. A partitioned index with indisvalid set to false is equivalent to an incomplete partition tree, meaning that an invalid partitioned index does not have indexes defined in all its partitions. Hence, choosing an invalid partitioned index can create inconsistent partition index trees, where the parent attaching to is valid, but its partition may be invalid. In the report from Alexander Lakhin, this showed up as an assertion failure when validating an index. Without assertions enabled, the partition index tree would be actually broken, as indisvalid should be switched to true for a partitioned index once all its partitions are themselves valid. With two levels of partitioning, the top partitioned table used a valid index and was able to link to an invalid index stored on its partition, itself a partitioned table. I have studied a few options here (like the possibility to switch indisvalid to false for the parent), but came down to the conclusion that we'd better rely on a simple rule: invalid indexes had better never be chosen, so as the partition attached uses and creates indexes that the parent expects. Some regression tests are added to provide some coverage. Note that the existing coverage is not impacted. This is a problem since partitioned indexes exist, so backpatch all the way down to v11. Reported-by: Alexander Lakhin Discussion: https://postgr.es/[email protected] Backpatch-through: 11 (cherry picked from commit fc55c7ff8d122feb48aae5889e26499ffe53c0b7)
Not including the timeline IDs to the file names generated by pg_waldump for the individual blocks saved could cause some of these files to be overwritten when scanning segments across multiple timelines. Having this information is also as much useful as the LSNs, to be able to know from exactly which WAL segment a block is comes from. While on it, this fixes a few comments in the tests, where the format of the file was not described as matching with the reality. Reported-by: Fujii Masao Reviewed-by: Kyotaro Horiguchi, David Christensen Discussion: https://postgr.es/m/[email protected] (cherry picked from commit b381d9637030c163c3b1f8a9d3de51dfc1b4ee58)
Re-word for more clarity, per gripe from Anton Sidyakin. Discussion: https://postgr.es/m/[email protected] (cherry picked from commit ac1e974221cb11465c126097243d5b5050b8d041)
(cherry picked from commit 046c8c5c8fe26fbce3ba773d49c81e6bbdf73db1)
Oversight in 6b4d23f. Author: Japin Li, Richard Guo Discussion: https://postgr.es/m/MEYP282MB1669FC91C764E277821936D3B624A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM Backpatch-through: 14 (cherry picked from commit dc73db67433c5a9ee0d7a7dc788178553ef8afce)
This should have been part of dc73db6, but it got lost in the mix. Oversight in 6b4d23f. Author: Japin Li Discussion: https://postgr.es/m/MEYP282MB1669FC91C764E277821936D3B624A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM Backpatch-through: 14 (cherry picked from commit bc8e9a6a25e1674d49b977c1d3fc80e7c22f5b30)
d913928c9c added support for the "S" modifier to psql's \dp and \z meta-commands, but it missed updating the corresponding entries in \?'s output. Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/DM4PR84MB17342A51B3A1556CFBC7A4B2EE25A%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM (cherry picked from commit dda9f8e7bc2e1e5cc6c77b86ce54786e9df8e0c6)
(cherry picked from commit 39a584dc90324b7323424d7450df8586ab2a0ca1)
It was walking into the ColumnDef->compression field, which is not a node but a string. This code is currently not reachable (because the compression field is only set in situations that don't go through raw_expression_tree_walker()), but if it had been, this could have behaved erratically. (cherry picked from commit efcf55f8fe00b46198cd34557431c87ce5da8040)
Triple-quoted strings are for multiline strings in Meson. None of the descriptions that got changed were multiline and the entire file uses single-line descriptions. Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit 559bdd58eb712d413aff662cf797a7a4598baf00)
Meson itself uses capital letters for option descriptions, so follow that. Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit 529449c379b9248ad1b2b8af308799a149a6d0c1)
Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit b2ec7f543f9e3b9ab1ad21e5512cfe5c6c2b4a6f)
This matches the style found in the rest of the Meson build description. Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit c55d31e59c8980147b2103cbcf5ef0c3e6434f70)
Previously in the build description, a not_found_dep was defined. Make use of it. Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit 38977dd2bdacdfa5ca36377d3197029993929d7f)
That portion of code is not run in the Windows case already given the structure of the surrounding if statement. Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit 45c88eecb4a6cf286b2bd8fc977ccf932525933a)
Using false to disable a feature option is incorrect. Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit f5159c734fe41526805c49d62c61fb2f320531e0)
Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit 74668cbf0fcc356faef271aa2fb42896e323f8b1)
Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit af492eb6d6c90cf470c544083d3b6b3648f1bea2)
Meson validates 'choice' options for us, so technically this case is impossible. A better error message helps people reading the code understand what is going on in that branch. Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit 99e57663518b0eaf8fa69d20d0e796321bc8e558)
Author: Tristan Partin <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po (cherry picked from commit b750e74e6ec324f4c9de82587cb6a07490f86cfe)
If the given composite datum is toasted out-of-line, DatumGetHeapTupleHeader will perform database accesses to detoast it. That can invalidate the result of get_cached_rowtype, as documented (perhaps not plainly enough) in that function's API spec; which leads to strange errors or crashes when we try to use the TupleDesc to read the tuple. In short then, trying to update a field of a composite column could fail intermittently if the overall column value is wide enough to require toasting. We can fix the bug at no cost by just changing the order of operations, since we don't need the TupleDesc until after detoasting. (Other callers of get_cached_rowtype appear to get this right already, so there's only one bug.) Note that the added regression test case reveals this bug reliably only with debug_discard_caches/CLOBBER_CACHE_ALWAYS. Per bug #17994 from Alexander Lakhin. Sadly, this patch does not fix the missing-values issue revealed in the bug discussion; we'll need some more work to cover that. Discussion: https://postgr.es/m/[email protected] (cherry picked from commit 43af714defa00145981eb542cb71647836b3efa4)
An outer join cannot be formed using an input path that is parameterized by a value that is supposed to be nulled by the outer join. This is obviously nonsensical, and it could lead to a bad plan being selected; although currently it seems that we'll hit various sanity-check assertions first. I think that such cases were formerly prevented by the delay_upper_joins mechanism, but now that that's gone we need an explicit check. (Perhaps we should avoid generating baserel paths that could lead to this situation in the first place; but it seems like having a defense at the join level would be a good idea anyway.) Richard Guo and Tom Lane, per report from Jaime Casanova Discussion: https://postgr.es/m/CAJKUy5g2uZRrUDZJ8p-=giwcSHVUn0c9nmdxPSY0jF0Ov8VoEA@mail.gmail.com (cherry picked from commit a798660ebe3ff1feb310db13b957c5cda4c8c50d)
run_command(check: true) already would have errorred out before the check is reached. Author: Tristan Partin <[email protected]> Discussion: CSPIJVUDZFKX.3KHMOAVGF94RV@c3po (cherry picked from commit 5f87a021257f1ea1cacdced0cf49ff1c58ecf5e9)
ALTER TABLE .. SET ACCESS METHOD was not registering a dependency to the new access method with the relation altered in its rewrite phase, making possible the drop of an access method even if there are relations that depend on it. During the rewrite, a temporary relation is created to build the new relation files before swapping the new and old files, and, while the temporary relation was registering a correct dependency to the new AM, the old relation did not do that. A dependency on the access method is added when the relation files are swapped, which is the point where pg_class is updated. Materialized views and tables use the same code path, hence both were impacted. Backpatch down to 15, where this command has been introduced. Reported-by: Alexander Lakhin Reviewed-by: Nathan Bossart, Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch-through: 15 (cherry picked from commit 97d89101045fac8cb36f4ef6c08526ea0841a596)
Also do a quick fix to get pg_hint_plan working with babelfish. Signed-off-by: Jason Teng <[email protected]>
2jungkook
approved these changes
Dec 20, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merge last 997 commits to get BABEL_main to pg16 branching point. No merge conflicts.
Extension PR for validation: amazon-aurora/babelfish_extensions#54