Re: locking [user] catalog tables vs 2pc vs logical rep - Mailing list pgsql-hackers

From vignesh C
Subject Re: locking [user] catalog tables vs 2pc vs logical rep
Date
Msg-id CALDaNm0iLuih4+Pd+LV1-57NrdR1uB0q=7twAgQ0nPVgaYapyw@mail.gmail.com
Whole thread Raw
In response to RE: locking [user] catalog tables vs 2pc vs logical rep  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Responses Re: locking [user] catalog tables vs 2pc vs logical rep
List pgsql-hackers
On Tue, Jun 8, 2021 at 1:34 PM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Monday, June 7, 2021 6:22 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila <amit.kapila16@gmail.com>
> > wrote:
> > >
> > > One more comment is that for HEAD, first just create a patch with
> > > synchronous replication-related doc changes and then write a separate
> > > patch for prepared transactions.
> > >
> >
> > I noticed that docs for "Synchronous replication support for Logical Decoding"
> > has been introduced by commit
> > 49c0864d7ef5227faa24f903902db90e5c9d5d69 which goes till 9.6. So, I think
> > you need to create a patch for 9.6 as well unless one of the existing patches
> > already applies in 9.6.
> OK. I could apply PG10's patch to 9.6.
> Also, I've made a separate patch for 2PC description.
>
> On the other hand, I need to mention that
> there are some gaps to cause failures to apply patches
> between supported versions.
> (e.g. applying a patch for HEAD to stable PG13 fails)
>
> To address the gaps between the versions,
> I needed to conduct some manual fixes.
> Therefore, please note that the content of patch
> between PG12 and PG13 are almost same
> like PG9.6 and PG10, but, I prepared
> independent patches for HEAD and PG11,
> in order to make those applied in a comfortable manner.
>
>
> Kindly have a look at the updated patch-set.
> They all passed the test of make html.

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)
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:
3) Should [user] catalog tables be catalog tables or user catalog tables
[user] catalog tables

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Next
From: Justin Pryzby
Date:
Subject: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic