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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: locking [user] catalog tables vs 2pc vs logical rep
Дата
Msg-id CAA4eK1KwMv+SvXBnrSwSmNPuCEmCUbedxLt9ViGNc3FCLZoPOg@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 Sun, Jun 20, 2021 at 9:28 AM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Saturday, June 19, 2021 6:51 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Fri, Jun 18, 2021 at 2:25 PM osumi.takamichi@fujitsu.com
> > <osumi.takamichi@fujitsu.com> wrote:
> > >
> > > On  Friday, June 18, 2021 11:41 AM osumi.takamichi@fujitsu.com
> > <osumi.takamichi@fujitsu.com> wrote:
> >
> > > > Simon, I appreciate your suggestions and yes, if the user catalog
> > > > table is referenced by the output plugin, it can be another cause of the
> > deadlock.
> > > >
> > > > I'm going to post the patch for the those two changes, accordingly.
> > > Hi, I've made the patch-set to cover the discussion above for all-supported
> > versions.
> > > Please have a look at those.
> >
> > I have slightly modified your patch, see if the attached looks okay to you? This
> > is just a HEAD patch, I'll modify the back-branch patches accordingly.
> Thank you for updating the patch.
> The patch becomes much better. Yet, I have one suggestion.
>
> * doc/src/sgml/logicaldecoding.sgml
>       <itemizedlist>
>        <listitem>
>         <para>
>          Issuing an explicit <command>LOCK</command> on <structname>pg_class</structname>
> -        (or any other catalog table) in a transaction.
> +        (or any other [user] catalog table) in a transaction.
>         </para>
>        </listitem>
>
>        <listitem>
>         <para>
> -        Perform <command>CLUSTER</command> on <structname>pg_class</structname> in
> -        a transaction.
> +        Perform <command>CLUSTER</command> on <structname>pg_class</structname> (or any
> +        other [user] catalog table) in a transaction.
>         </para>
>        </listitem>
>
>        <listitem>
>         <para>
>          <command>PREPARE TRANSACTION</command> after <command>LOCK</command> command
> -        on <structname>pg_class</structname> and allow logical decoding of two-phase
> -        transactions.
> +        on <structname>pg_class</structname> (or any other [user] catalog table) and
> +        allow logical decoding of two-phase transactions.
>         </para>
>        </listitem>
>
>        <listitem>
>         <para>
>          <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.
> +        command on <structname>pg_trigger</structname> (or any other [user] catalog
> +        table) and allow logical decoding of two-phase transactions. This will lead
> +        to deadlock only when published table have a trigger.
>
>
> Now we have the four paren supplementary descriptions,
> not to make users miss any other [user] catalog tables.
> Because of this, the built output html gives me some redundant
> impression, for that parts. Accordingly, couldn't we move them
> to outside of the itemizedlist section in a simple manner ?
>
> For example, to insert a sentence below the list,
> after removing the paren descriptions in the listitem, which says
> "Note that those commands that can cause deadlock apply to not only
> explicitly indicated system catalog tables above but also any other [user] catalog table."
>

Sounds reasonable to me. /but also any other/but also to any other/,
to seems to be missing in the above line. Kindly send an update patch.

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: pgbench logging broken by time logic changes
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: pgbench logging broken by time logic changes