On Thu, May 13, 2021 at 11:15 AM osumi.takami...@fujitsu.com <osumi.takami...@fujitsu.com> wrote: > > On Thursday, April 29, 2021 2:31 PM Amit Kapila <amit.kapil...@gmail.com> > wrote: > > I am not so sure about it because I think we don't have any example of > > user_catalog_tables in the core code. This is the reason I was kind of > > looking > > towards Andres to clarify this. Right now, if the user performs TRUNCATE on > > user_catalog_table in synchronous mode then it will hang in case the > > decoding plugin takes even share lock on it. The main reason is that we > > allow > > decoding of TRUNCATE operation for user_catalog_tables. I think even if we > > want to allow decoding of other operations on user_catalog_table, the > > decoding of TRUNCATE should be prohibited but maybe we shouldn't allow > > decoding of any operation on such tables as we don't do it for system > > catalog > > tables. > > I tried the following scenarios for trying to reproduce this. > > Scenario1: > (1) set up 1 publisher and 1 subscriber > (2) create table with user_catalog_table = true on the pub > (3) insert some data to this table > (4) create publication for the table on the pub > (5) create table with user_catalog_table = true on the sub > (6) create subscription on the sub > (7) add synchronous_standby_names to publisher's configuration and restart > the pub > (8) have 1 session to hold a lock to the user_catalog_table on the pub in > access share mode > (9) have another session to truncate the user_catalog_table on the pub > > Here, It keeps waiting but I'm not sure this is the scenario described above, > since this deadlock is caused by (8)'s lock. >
This is a lock time-out scenario, not a deadlock. > Scenario2: > (1) set up 1 publisher and 1 subscriber > (2) create table with user_catalog_table = true on the pub > (3) insert some data to this table > (4) create publication for the table on the pub > (5) create table with user_catalog_table = true on the sub > (6) create subscription on the sub > (7) add synchronous_standby_names to publisher's configuration and restart > the pub > (8) have a session to truncate the user_catalog_table on the pub > > Scenario 2 was successful. > Yeah, because pgoutput or for that matter even test_decoding doesn't acquire a lock on user catalog tables. > Are these the scenario you have in mind, > if not please let me know for the missing steps. > I would like to reproduce the scenario and write a patch to fix this. > I don't think we can reproduce it with core plugins as they don't lock user catalog tables. We either need to write a minimal decoding plugin where we acquire a lock (maybe share lock) on the user catalog table or hack test_decoding/pgoutput to take such a lock. -- With Regards, Amit Kapila.
