Re: Forget close an open relation in ReorderBufferProcessTXN() - Mailing list pgsql-hackers

On Thu, May 13, 2021 at 11:15 AM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Thursday, April 29, 2021 2:31 PM Amit Kapila <amit.kapila16@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.