greenplum-db / gpdb-postgres-merge-archived Goto Github PK

As discussed, we need to revert 7e81c4b first before merging this branch to GPDB master.

GPDB master is now derived from PG_94_STABLE in which 7e81c4b reverted some commits. however, PG_95 still keep those commits reverted by 7e81c4b.

A note from daniel:

let's make a note of it to ensure that we cherry-pick it into master just before the merge, so that the reverted commit isn’t introduced as part of the merge where it shouldn’t be

w/ @melanieplageman

postgres=# create extension gp_inject_fault;
ERROR:  extension "gp_inject_fault" already exists  (seg0 127.0.1.1:25435 pid=14567)
postgres=# drop extension gp_inject_fault;
ERROR:  extension "gp_inject_fault" does not exist 

However, as pg_regress does, CREATE EXTENSION IF NOT EXISTS works.

checkpoint_segments has been replaced by max_wal_size and min_wal_size, GPDB used to allow users to specify checkpoint_segments in gpinitsystem, do we need to support max_wal_size or min_wal_size in gpinitsystem too?

ICG ORCA failures in iteration_9 (check the box after fixing the issue)

teach ORCA translator about invalid constraints:

• alter_table

flakes?

• instr_in_shmem_verify

super slow query with ORCA

• subselect

mac sorts differently from linux?

• decode_expr

stale ORCA expect files:

• union
• rangefuncs
• function_extensions
• update_gp
• table_functions
• co_nestloop_idxscan
• subselect_gp
• partition_locking (we're not sure though)
• portals_updatable
• bfv_dd
• bb_mpph
• qp_correlated_query
• gporca
• bfv_index
• olap_window_seq
• bfv_subquery

CTE

• qp_misc_jiras
• qp_derived_table
• qp_olap_window
• qp_with_clause
• with_clause

no clue

• gpctas
• sreh
• bfv_partition
• qp_dropped_cols
• query_info_hook_test
• bfv_aggregate
• inherit

crashing sadly

• qp_targeted_dispatch
• qp_functions
• qp_correlated_query
• qp_misc_rio_join_small
• qp_misc_rio
• qp_gist_indexes2
• qp_gist_indexes3
• qp_gist_indexes4
• qp_query_execution
• dpe
• qp_dpe
• qp_subquery
• qp_left_anti_semi_join
• qp_union_intersect
• qp_functions_idf
• qp_regexp
• qp_resource_queue
• qp_orca_fallback

Steps to reproduce:

$ gpconfig -c gp_enable_global_deadlock_detector -v on
$ gpstop -air  # GUC above requires server restart

In session 1 run:

CREATE TABLE t AS SELECT * FROM generate_series(1, 4) AS id;
BEGIN;
SELECT * FROM t WHERE id = 2 FOR UPDATE; -- should acquire update lock on tuple 2

In session 2 run:

SELECT * FROM t FOR UPDATE SKIP LOCKED;

Expected result of session 2:

# SELECT * FROM t FOR UPDATE SKIP LOCKED;
 id
----
  1
  3
  4
(3 rows)

Actual result of session 2:

# SELECT * FROM t FOR UPDATE SKIP LOCKED;
 id
----
  1
  2
  3
  4
(4 rows)

Explain plan of planner:

postgres=# EXPLAIN SELECT * FROM t_demo_heap FOR UPDATE SKIP LOCKED;
                                 QUERY PLAN
-----------------------------------------------------------------------------
 Gather Motion 3:1  (slice1; segments: 3)  (cost=0.00..2.08 rows=4 width=10)
   ->  LockRows  (cost=0.00..2.08 rows=2 width=10)
         ->  Seq Scan on t_demo_heap  (cost=0.00..2.04 rows=2 width=10)
 Optimizer: Postgres query optimizer
(4 rows)

Explain plan of orca:

postgres=# EXPLAIN SELECT * FROM t_demo_heap FOR UPDATE SKIP LOCKED;
                                  QUERY PLAN
------------------------------------------------------------------------------
 Gather Motion 3:1  (slice1; segments: 3)  (cost=0.00..431.00 rows=4 width=4)
   ->  Seq Scan on t_demo_heap  (cost=0.00..431.00 rows=2 width=4)
 Optimizer: Pivotal Optimizer (GPORCA) version 3.49.0
(3 rows)