Re: locking [user] catalog tables vs 2pc vs logical rep

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: locking [user] catalog tables vs 2pc vs logical rep
Дата
Msg-id 1425177.1621999648@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: locking [user] catalog tables vs 2pc vs logical rep  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: locking [user] catalog tables vs 2pc vs logical rep
Следующее
От: David Rowley
Дата:
Сообщение: Re: Hybrid Hash/Nested Loop joins and caching results from subplans