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

Поиск
Список
Период
Сортировка
От osumi.takamichi@fujitsu.com
Тема RE: locking [user] catalog tables vs 2pc vs logical rep
Дата
Msg-id OSBPR01MB48882769206E2125B506F1F5ED0E9@OSBPR01MB4888.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: locking [user] catalog tables vs 2pc vs logical rep  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: locking [user] catalog tables vs 2pc vs logical rep  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Wednesday, June 16, 2021 7:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Jun 14, 2021 at 5:33 PM osumi.takamichi@fujitsu.com
> <osumi.takamichi@fujitsu.com> wrote:
> >
> > On  Friday, June 11, 2021 2:13 PM  vignesh C <vignesh21@gmail.com>
> wrote:
> >
> > Attached the patch-set that addressed those two comments.
> >
> 
> Few minor comments:
> 1.
> +      <listitem>
> +       <para>
> +        Clustering <structname>pg_class</structname> in a transaction.
> 
> Can we change above to: Perform <command>CLUSTER</command> on
> <structname>pg_class</structname> in a transaction.
Looks better.

> 
> 2.
> +      <listitem>
> +       <para>
> +        Executing <command>TRUNCATE</command> on user catalog
> table
> in a transaction.
> +       </para>
> 
> Square brackets are missing for user.
Thanks for catching it. You are right.


> 3.
> +    <indexterm>
> +     <primary>Overview</primary>
> +    </indexterm>
> ..
> ..
> +    <indexterm>
> +     <primary>Caveats</primary>
> +    </indexterm>
> 
> Why are these required when we already have titles? I have seen other places
> in the docs where we use titles for Overview and Caveats but they didn't have
> similar usage.
Sorry, this was a mistake. We didn't need those sections.


> 4.
> <para>
> +        Performing <command>PREPARE TRANSACTION</command>
> after
> <command>LOCK</command>
> +        command on <structname>pg_class</structname> and logical
> decoding of published
> +        table.
> 
> Can we change above to: <command>PREPARE
> TRANSACTION</command> after <command>LOCK</command>
> command on <structname>pg_class</structname> and allow logical
> decoding of two-phase transactions.
> 
> 5.
> +       <para>
> +        Clustering <structname>pg_trigger</structname> and decoding
> <command>PREPARE
> +        TRANSACTION</command>, if any published table have a trigger
> and any
> +        operations that will be decoded are conducted.
> +       </para>
> 
> Can we change above to: <command>PREPARE
> TRANSACTION</command> after <command>CLUSTER</command>
> command on <structname>pg_trigger</structname> and allow logical
> decoding of two-phase transactions. This will lead to deadlock only when
> published table have a trigger.
Yeah, I needed the nuance to turn on logical decoding of two-phase transactions...
Your above suggestions are much tidier and more accurate than mine.
I agree with your all suggestions.


Best Regards,
    Takamichi Osumi


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

Предыдущее
От: Zhihong Yu
Дата:
Сообщение: Re: Centralizing protective copying of utility statements
Следующее
От: Yugo NAGATA
Дата:
Сообщение: Re: pgbench logging broken by time logic changes