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

Поиск
Список
Период
Сортировка
От vignesh C
Тема Re: locking [user] catalog tables vs 2pc vs logical rep
Дата
Msg-id CALDaNm0Y+jEdV8n=Qsbd+4TDVHcgQTEG=fW89fYimwF2+sOfkA@mail.gmail.com
обсуждение исходный текст
Ответ на RE: locking [user] catalog tables vs 2pc vs logical rep  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Ответы RE: locking [user] catalog tables vs 2pc vs logical rep  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Список pgsql-hackers
On Wed, Jun 9, 2021 at 12:03 PM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Wednesday, June 9, 2021 12:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Tue, Jun 8, 2021 at 6:24 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > > Thanks for the updated patch.
> > >
> > > I have few comments:
> > > 1) Should we list the actual system tables like pg_class,pg_trigger,
> > > etc instead of any other catalog table?
> > > User has issued an explicit LOCK on pg_class (or any other catalog
> > > table)
> > >
> >
> > I think the way it is mentioned is okay. We don't need to specify other catalog
> > tables.
> Okay.
>
>
> > > 2) Here This means deadlock, after this we mention deadlock again for
> > > each of the examples, we can remove it if redundant.
> > > This can happen in the following ways:
> I think this sentence works to notify that commands described below
> are major scenarios naturally, to the readers. Then, I don't want to remove it.
>
> If you somehow feel that the descriptions are redundant,
> how about unifying all listitems as nouns. like below ?
>
> * An explicit <command>LOCK</command> on <structname>pg_class</structname> (or any other catalog table) in a
transaction
> * Reordering <structname>pg_class</structname> by <command>CLUSTER</command> command in a transaction
> * Executing <command>TRUNCATE</command> on user_catalog_table
>

This looks good to me. Keep the 2PC documentation patch also on the same lines.

Regards,
Vignesh



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: logical replication of truncate command with trigger causes Assert
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options