Regression test `add_table` failing in PG17 RHEL9 x86_64 machines

[xinxinzhenhuai]

Hi team. I am seeing this test add_table failing in PG17 RHEL9 x86_64 machines.
The diff is not the same across runs so I am assuming the test is still flaky? Any update on this issue? Is this test still flaky?
I saw there was already a post many years ago #126. Any update on this test? Shall I just ignore it for now?

# 1 of 29 tests failed.
     # The differences that caused some tests to fail can be viewed in the file "/workspace/extensions/pglogical/regression_output/regression.diffs".
     # A copy of the test summary that you see above is saved in the file "/workspace/extensions/pglogical/regression_output/regression.out".
     make: *** [Makefile:146: regresscheck] Error 1
     diff -U3 /workspace/extensions/pglogical/expected/add_table.out /workspace/extensions/pglogical/regression_output/results/add_table.out
     --- /workspace/extensions/pglogical/expected/add_table.out	2025-05-14 22:47:50.322807618 +0000
     +++ /workspace/extensions/pglogical/regression_output/results/add_table.out	2025-05-14 23:30:47.889177006 +0000
     @@ -219,16 +219,12 @@
      BEGIN;
      SET statement_timeout = '20s';
      SELECT pglogical.wait_for_table_sync_complete('test_subscription', 'test_nosync');
     - wait_for_table_sync_complete 
     -------------------------------
     - 
     -(1 row)
     -
     +ERROR:  canceling statement due to statement timeout
      COMMIT;
      SELECT sync_kind, sync_subid, sync_nspname, sync_relname, sync_status IN ('y', 'r') FROM pglogical.local_sync_status ORDER BY 2,3,4;
       sync_kind | sync_subid |   sync_nspname    |    sync_relname    | ?column? 
      -----------+------------+-------------------+--------------------+----------
     - d         | 3848008564 | public            | test_nosync        | t
     + d         | 3848008564 | public            | test_nosync        | f
       d         | 3848008564 | public            | test_publicschema  | t
       d         | 3848008564 | strange.schema-IS | test_strangeschema | t
       f         | 3848008564 |                   |                    | t
     @@ -257,17 +253,13 @@
      BEGIN;
      SET statement_timeout = '20s';
      SELECT pglogical.wait_for_table_sync_complete('test_subscription', 'test_publicschema');
     - wait_for_table_sync_complete 
     -------------------------------
     - 
     -(1 row)
     -
     +ERROR:  canceling statement due to statement timeout
      COMMIT;
      SELECT sync_kind, sync_subid, sync_nspname, sync_relname, sync_status IN ('y', 'r') FROM pglogical.local_sync_status ORDER BY 2,3,4;
       sync_kind | sync_subid |   sync_nspname    |    sync_relname    | ?column? 
      -----------+------------+-------------------+--------------------+----------
     - d         | 3848008564 | public            | test_nosync        | t
     - d         | 3848008564 | public            | test_publicschema  | t
     + d         | 3848008564 | public            | test_nosync        | f
     + d         | 3848008564 | public            | test_publicschema  | f
       d         | 3848008564 | strange.schema-IS | test_strangeschema | t
       f         | 3848008564 |                   |                    | t
      (4 rows)
     @@ -275,18 +267,14 @@
      SELECT * FROM public.test_publicschema;
       data | id 
      ------+----
     - a    |  1
     - b    |  2
     - c    |  3
     - d    |  4
     -(4 rows)
     +(0 rows)
      
      \x
      SELECT nspname, relname, status IN ('synchronized', 'replicating') FROM pglogical.show_subscription_table('test_subscription', 'test_publicschema');
      -[ RECORD 1 ]---------------
      nspname  | public
      relname  | test_publicschema
     -?column? | t
     +?column? | f
      
      \x
      BEGIN;