Catchup 1X_STABLE #175
Merged
Catchup 1X_STABLE #175
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
Three unstable tests matching reindex/reindextable_while_reindex_idx_*_part_btree are fixed. They failed in the same way thus could be fixed in the same manner. These tests actually assumes when txn1 commits, its lock is acquired by txn3, and txn2 is blocked by it. Normally this is the case, but when the system load is high (e.g., when parallel is enabled, or other processes stress the system), it could be the case that the scheduler pass the access exclusive lock acquired by txn1 to txn2 (not txn3) in L22-L23, invalidate the assumption, causing the test to fail. Here I workaround this by instead of relying on the only one expected file which cannot checks two behaviour, SQL statement is used to directly check the correctness of one column. This problem is also found in the upstream, mainline GPDB. See: Issue#26 <cloudberrydb#26 (comment)>
Cherry-picked from greenplum-db/gpdb#16160 This is fixed by setting 'relocatable=false' and 'schema' to make extension responding to SCHEMA option of CREATE EXTENSION. I expand the PR from two extensions to all four problematic extensions. This is preferred over setting and referencing search_path directly in the extension install script - which leads to issues such as cloudberrydb#59. Also take out 'relocatable=true' as these extensions were never relocatable to begin with due to their explicit need to create everything under public (and besides relocatable and schema are conflicting options). See: https://github.com/greenplum-db/gpdb/pull/16160 See: Issue#59 <cloudberrydb#59> Co-authored-by: Soumyadeep Chakraborty <soumyadeep2007@gmail.com>
…loudberrydb#152) As before, we start by prepending one underscore (truncating the base name if necessary). But if there is a conflict, then instead of prepending more and more underscores, append an underscore and some digits, in much the same way that ChooseRelationName does. While the previous logic could be driven to fail by creating a lot of types with long names differing only near the end, this version seems certain enough to eventually succeed that we can remove the failure code path that was there before. While at it, undo 6df7a96's decision to split this code out of makeArrayTypeName. That wasn't actually accomplishing anything, because no other function was using it --- and it would have been wrong to do so. The convention that a prefix "_" means an array, not something else, is too ancient to mess with. Andrey Lepikhov and Dmitry Koval, reviewed by Masahiko Sawada and myself Discussion: https://postgr.es/m/b84cd82c-cc67-198a-8b1c-60f44e1259ad@postgrespro.ru Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>
We drop all outer paths who have Motion of parallel plan to avoid
deadlock when mixing parallel-aware hashjoin with parallel-oblivious
paths.
And we fix it to enable_parallel, which is stricter than needed.
It's possible to keep such a path when enable_parallel is on and
enable_parallel_hash is off.
Because we can make sure that there is no parallel-aware hashjoin,
and of course, no deadlock issues like above.
By loosening the restriction to enable_parallel_hash, such parallel
-oblivious plan would be possible.
explain(costs off) select * from t1 right join t2 on t1.b = t2.a;
QUERY PLAN
------------------------------------------------------------------
Gather Motion 6:1 (slice1; segments: 6)
-> Hash Left Join
Hash Cond: (t2.a = t1.b)
-> Redistribute Motion 6:6 (slice2; segments: 6)
Hash Key: t2.a
Hash Module: 3
-> Parallel Seq Scan on t2
-> Hash
-> Redistribute Motion 3:6 (slice3; segments: 3)
Hash Key: t1.b
Hash Module: 3
-> Seq Scan on t1
Optimizer: Postgres query optimizer
(13 rows)
Authored-by: Zhang Mingli avamingli@gmail.com
…rydb#154) The name “json_object” conflicts with the name of the jansson library. To avoid this conflict, change the name to pg_json_object.
create_bitmap_subplan() will try to convert subplan
to a bitmap indexscan, add locus info for that.
QUERY PLAN
--------------------------------------------
Gather Motion 6:1 (slice1; segments: 6)
Locus: Entry
-> Parallel Bitmap Heap Scan on t1
Locus: HashedWorkers
Parallel Workers: 2
-> Bitmap Index Scan on t1_c2_idx
Locus: Hashed
It's reasonable to eliminate Parallel Workers info.
Because a Bitmap Index Scan under Parallel Bitmap Heap Scan
will only be taken by one procress as the Postgres Doc:
In a parallel bitmap heap scan, one process is chosen as the leader.
That process performs a scan of one or more indexes and builds a
bitmap indicating which table blocks need to be visited.
These blocks are then divided among the cooperating processes as in
a parallel sequential scan.
In other words, the heap scan is performed in parallel, but the
underlying index scan is not.
Authored-by: Zhang Mingli avamingli@gmail.com
my-ship-it
approved these changes
Aug 31, 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.
This PR catches 1X_STABLE up with master because our release pipeline need those newer fixes. Somebody had already cherry-picked some newer PR from main w/o take its predecessors. I rebase from the beginning.