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 OSBPR01MB4888F0A6D137ACE1B1CBBB37ED0B9@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 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."


Best Regards,
    Takamichi Osumi


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

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