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

Поиск
Список
Период
Сортировка
От vignesh C
Тема Re: locking [user] catalog tables vs 2pc vs logical rep
Дата
Msg-id CALDaNm0iLuih4+Pd+LV1-57NrdR1uB0q=7twAgQ0nPVgaYapyw@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  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Matthias van de Meent
Дата:
Сообщение: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic