eaydingol

There is a typo in the pr description. Why is this change needed?

The PR adds ability to propagate "ALTER DATABASE ..." statement from any node with the last commits. It would be good to update the PR description to reflect this.

The order in which the locks are acquired depends on the worker initiating the UPDATE statement (first worker or others), which causes the deadlock.

We still see reuse of the same subplan id for the first case, but then error out in a later stage: ``` SELECT COUNT(*) FROM local JOIN distributed d1 USING...

I also reviewed the issue and agree with the previous comments — it is reproducible when citus_prepare_pg_upgrade() is skipped. One note, though: the first step in our documentation might be...

Investigated the issue with @onurctirtir. After recursive planning, the second query (Q2 with left join) becomes to Q2' where dist_1 is the only distributed table. In this case, Citus determines...

> ## Potential Backward Compatibility Issues Detected > This PR contains changes that may break backward compatibility: > > * **SQL Migration**: Column addition/removal in pg_catalog > > * File:...

To test locally: ``` export BASE_SHA="v11.1.0" export HEAD_SHA="v11.2.0" export PR_NUMBER="123" python3 ci/check-backward-compatibility.py cat /tmp/compat-results.json ``` Sample test results: ``` v11.2.0 to v11.3.0 - **SQL Migration**: Column addition/removal in pg_catalog -...

Reproduced in a one node cluster. On a multi-node citus cluster, the second distributed table creation step fails with the following error. ``` select create_distributed_table('t2', 'a'); ERROR: cannot colocate tables...