Repository: citusdata/citus

Issue #3190: Some of the distributed object propagation is not blocked by master_add_node
Created: 2019-11-14T14:22:56Z
--session 1
 CREATE TYPE t1 AS (a int, b int);
 CREATE TABLE test (a int, b t1);
-- t1 becomes a distributed object
SELECT create_distributed_table('test', 'a');

BEGIN;
select master_add_node('localhost', 9702);

Now, from session  2, which is finishes without being blocked:
 alter type t1  add ATTRIBUTE x int;
--back to session  1
COMMIT;

SELECT run_command_on_workers($$SELECT '(1,1,1)'::t1$$);
┌─[ RECORD 1 ]───────────┬────────────────────────────────────────────────────────────────────┐
│ run_command_on_workers │ (localhost,9700,t,"(1,1,1)")                                       │
├─[ RECORD 2 ]───────────┼────────────────────────────────────────────────────────────────────┤
│ run_command_on_workers │ (localhost,9701,t,"(1,1,1)")                                       │
├─[ RECORD 3 ]───────────┼────────────────────────────────────────────────────────────────────┤
│ run_command_on_workers │ (localhost,9702,f,"ERROR:  malformed record literal: ""(1,1,1)""") │
└────────────────────────┴────────────────────────────────────────────────────────────────────┘


SELECT run_command_on_workers($$SELECT '(1,1)'::t1$$);
┌─[ RECORD 1 ]───────────┬──────────────────────────────────────────────────────────────────┐
│ run_command_on_workers │ (localhost,9700,f,"ERROR:  malformed record literal: ""(1,1)""") │
├─[ RECORD 2 ]───────────┼──────────────────────────────────────────────────────────────────┤
│ run_command_on_workers │ (localhost,9701,f,"ERROR:  malformed record literal: ""(1,1)""") │
├─[ RECORD 3 ]───────────┼──────────────────────────────────────────────────────────────────┤
│ run_command_on_workers │ (localhost,9702,t,"(1,1)")                                       │
└────────────────────────┴──────────────────────────────────────────────────────────────────┘
So, the types diverged. I think we should have a generic solution for master_add_node vs object propagation

Duplicate issue #1199: Improve concurrent start_metadata_sync_to_node and other metadata changes
Created: 2017-02-02T14:05:04Z
Running concurrent metadata changes and start_metadata_sync_to_node() may lead to failures / unexpected metadata.
Things to consider:

start_metadata_sync_to_node() / ALTER TABLE
start_metadata_sync_to_node() / DROP TABLE
start_metadata_sync_to_node() / CREATE FKEY
start_metadata_sync_to_node() / create_dist_table() / create_reference_table()
start_metadata_sync_to_node() / upgrade_to_reference_table [ignore]
start_metadata_sync_to_node() / mark_tables_colocated [ignore]
Note that the above may not be the full list, the owner of the task should consider other UDFs/operations as well.

One example:
Session 1:
SELECT start_metadata_sync_to_node('localhost', 9700);
Session 2:
ALTER TABLE t1 add column x int;
NOTICE:  using one-phase commit for distributed DDL commands
HINT:  You can enable two-phase commit for extra safety with: SET citus.multi_shard_commit_protocol TO '2pc'
WARNING:  connection error: localhost:9700
DETAIL:  no connection to the server
ERROR:  failure on connection marked as essential: localhost:9700
A comment from @marcocitus from the test doc:
pg_get_tableschemadef_string, which generates the CREATE TABLE command, does acquire an AccessShareLock on the table, which blocks ALTER TABLE, but it also releases it at the end of the function.

Closing comment (2021-12-21T13:29:08Z): could be related to #3190