Hi
I've been discussing about user_catalog_table
and the possibility of deadlock during synchronous mode
of logical replication in [1]. I'll launch a new thread
and summarize the contents so that anyone who is
interested in this title can join the discussion.
We don't have any example of user_catalog_tables
in the core code, so any response and idea related to this area is helpful.
Now, we don't disallow output plugin to take a lock
on user_catalog_table. Then, we can consider a deadlock scenario like below.
1. TRUNCATE command is performed on user_catalog_table.
2. TRUNCATE command locks the table and index with ACCESS EXCLUSIVE LOCK.
3. TRUNCATE waits for the subscriber's synchronization
when synchronous_standby_names is set.
4. Here, the walsender hangs, *if* it tries to acquire a lock on the
user_catalog_table
because the table where it wants to see is locked by the TRUNCATE
already.
(Here, we don't talk about LOCK command because
the discussion is in progress in another thread independently - [2])
Another important point here is that we can *not*
know how and when plugin does read only access to user_catalog_table in general,
because it depends on the purpose of the plugin.
Then, I'm thinking that changing a behavior of TRUNCATE side
to error out when TRUNCATE is performed on user_catalog_table
will work to make the concern disappear. Kindly have a look at the attached
patch.
[1] -
https://www.postgresql.org/message-id/MEYP282MB166933B1AB02B4FE56E82453B64D9%40MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
[2] -
https://www.postgresql.org/message-id/CALDaNm1UB==gl9poad4etjfcygdjbphwezezocodnbd--kj...@mail.gmail.com
Best Regards,
Takamichi Osumi
disallow_TRUNCATE_on_user_catalog_table_v01.patch
Description: disallow_TRUNCATE_on_user_catalog_table_v01.patch
