Re: locking [user] catalog tables vs 2pc vs logical rep - Mailing list pgsql-hackers

From Tom Lane
Subject Re: locking [user] catalog tables vs 2pc vs logical rep
Date
Msg-id 1425177.1621999648@sss.pgh.pa.us
Whole thread Raw
In response to Re: locking [user] catalog tables vs 2pc vs logical rep  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> Fair enough. But the way we were looking at them as they will also
> block (lead to deadlock) for logical replication of prepared
> transactions and also logical replication in synchonous mode without
> prepared transactions. Now, if we want to deal with the 2PC issues
> separately that should be fine as well. However, for that we need to
> see which all operations we want to block on [user]_catalog_tables.
> The first one is lock command, then there are other operations like
> Cluster which take exclusive lock on system catalog tables and we
> allow them to be part of prepared transactions (example Cluster
> pg_trigger using pg_trigger_oid_index;), another kind of operation is
> Truncate on user_catalog_tables. Now, some of these might not allow
> connecting after restart so we might need to think whether we want to
> prohibit all such operations or only some of them.

2PC has pretty much always worked like that, and AFAIR there have been
a grand total of zero complaints about it.  It seems quite likely to
me that you're proposing to expend a lot of effort on restrictions
that will hurt more people than they help.  Maybe that score is only
about one to zero, but still you should account for the possibility
that you're breaking legitimate use-cases.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: locking [user] catalog tables vs 2pc vs logical rep
Next
From: David Rowley
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans