[Bug] pax flaky case failed

[avamingli]

Apache Cloudberry version

main

What happened

case failed in PR #1098 :

Found regression.diffs at: ./contrib/pax_storage/src/test/regress/regression.diffs
diff -I HINT: -I CONTEXT: -I GP_IGNORE: -U3 /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/expected/lock.out /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/results/lock.out
--- /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/expected/lock.out	2025-05-14 01:54:12.907013626 -0700
+++ /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/results/lock.out	2025-05-14 01:54:12.913013637 -0700
@@ -64,21 +64,23 @@
 select l.gp_segment_id, relname from pg_locks l, pg_class c
  where l.relation = c.oid and relname like '%lock_%' and mode = 'ExclusiveLock'
  order by relname;
- gp_segment_id |  relname   
----------------+------------
+ gp_segment_id |         relname         
+---------------+-------------------------
              0 | lock_tbl1
              0 | lock_tbl1a
              0 | lock_view2
+             0 | pg_pax_blocks_50065
              1 | lock_tbl1
              1 | lock_tbl1a
              1 | lock_view2
+             1 | pg_pax_blocks_50065_idx
              2 | lock_tbl1
              2 | lock_tbl1a
              2 | lock_view2
             -1 | lock_tbl1
             -1 | lock_tbl1a
             -1 | lock_view2
-(12 rows)
+(14 rows)
 
 ROLLBACK;
 BEGIN TRANSACTION;

I'm pretty sure this PR has nothing to do with PAX, no change for that.

And I found the case failed even on our commits 964756f in main branch
https://github.com/apache/cloudberry/actions/runs/14927589884/job/41936745203

/__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/results/lock.out
--- /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/expected/lock.out	2025-05-09 04:31:34.624629466 -0700
+++ /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/results/lock.out	2025-05-09 04:31:34.629629414 -0700
@@ -160,17 +160,[18](https://github.com/apache/cloudberry/actions/runs/14993002873/job/42121794920#step:18:19) @@
 select l.gp_segment_id, relname from pg_locks l, pg_class c
  where l.relation = c.oid and relname like '%lock_%' and mode = 'ExclusiveLock'
  order by relname;
- gp_segment_id |  relname   
----------------+------------
+ gp_segment_id |       relname       
+---------------+---------------------
              0 | lock_tbl1
              0 | lock_view6
+             0 | pg_pax_blocks_50136
              1 | lock_tbl1
              1 | lock_view6
              2 | lock_tbl1
              2 | lock_view6
             -1 | lock_tbl1
             -1 | lock_view6
-(8 rows)
+(9 rows)

What you think should happen instead

No response

How to reproduce

CI

Operating System

CI

Anything else

No response

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct.

[avamingli]

Again in PR #1098 https://github.com/apache/cloudberry/actions/runs/15015871210/job/42206890531

diff -I HINT: -I CONTEXT: -I GP_IGNORE: -U3 /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/expected/lock.out /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/results/lock.out
--- /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/expected/lock.out	2025-05-14 05:03:40.736075537 -0700
+++ /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/results/lock.out	2025-05-14 05:03:40.742075537 -0700
@@ -87,8 +87,8 @@
 select l.gp_segment_id, relname from pg_locks l, pg_class c
  where l.relation = c.oid and relname like '%lock_%' and mode = 'ExclusiveLock'
  order by relname;
- gp_segment_id |  relname   
----------------+------------
+ gp_segment_id |         relname         
+---------------+-------------------------
              0 | lock_tbl1
              0 | lock_tbl1a
              0 | lock_view2
@@ -97,6 +97,7 @@
              1 | lock_tbl1a
              1 | lock_view2
              1 | lock_view3
+             1 | pg_pax_blocks_50055_idx
              2 | lock_tbl1
              2 | lock_tbl1a
              2 | lock_view2
@@ -105,7 +106,7 @@
             -1 | lock_tbl1a
             -1 | lock_view2
             -1 | lock_view3
-(16 rows)
+(17 rows)

And another in pr #1102, https://github.com/apache/cloudberry/actions/runs/15018549855/job/42205515485

--- /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/expected/lock.out	2025-05-14 04:40:21.307904182 -0700
+++ /__w/cloudberry/cloudberry/contrib/pax_storage/src/test/regress/results/lock.out	2025-05-14 04:40:21.313904210 -0700
@@ -160,17 +160,18 @@
 select l.gp_segment_id, relname from pg_locks l, pg_class c
  where l.relation = c.oid and relname like '%lock_%' and mode = 'ExclusiveLock'
  order by relname;
- gp_segment_id |  relname   
----------------+------------
+ gp_segment_id |         relname         
+---------------+-------------------------
              0 | lock_tbl1
              0 | lock_view6
              1 | lock_tbl1
              1 | lock_view6
              2 | lock_tbl1
              2 | lock_view6
+             2 | pg_pax_blocks_50049_idx
             -1 | lock_tbl1
             -1 | lock_view6
-(8 rows)
+(9 rows)

[my-ship-it]

@gfphoenix78 please take a look, thanks!

[gfphoenix78]

@gfphoenix78 please take a look, thanks!

Sure, I'll look into it ASAP.

[gfphoenix78]

autovacuum is disabled around the lock test. But many tests runs concurrently with the lock test in a group. It's hard to know whether the relation pg_pax_blocks_xxx is an auxiliary table of the pax in current session or other concurrently running session.

In pax code, the auxiliary table will not be locked in exclusive mode explicitly. The lock is probably held in other sessions.

[avamingli]

Fixed in 49a0135