Re: Perform streaming logical transactions by background workers and parallel apply - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Perform streaming logical transactions by background workers and parallel apply
Date
Msg-id CAFiTN-vOovtK2ENFqat8fUndhqvPeT+Latd2SKA3GmQitkQK3g@mail.gmail.com
Whole thread Raw
In response to Re: Perform streaming logical transactions by background workers and parallel apply  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Oct 18, 2022 at 6:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Interesting case.  So I think the root of the problem is the same as
> > what we have for a column is marked unique to the subscriber but not
> > to the publisher.  In short, two transactions which are independent of
> > each other on the publisher are dependent on each other on the
> > subscriber side because table definition is different on the
> > subscriber.  So can't we handle this case in the same way by marking
> > this table unsafe for parallel-apply?
> >
>
> Yes, we can do that. I think Hou-San has already dealt that way in his
> latest patch [1]. See his response in the email [1]: "Disallow
> replicating from or to a partitioned table in parallel streaming
> mode".
>
> [1] -
https://www.postgresql.org/message-id/OS0PR01MB57160760B34E1655718F4D1994249%40OS0PR01MB5716.jpnprd01.prod.outlook.com

Okay, somehow I missed the latest email.  I will look into it soon.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Zhang Mingli
Date:
Subject: Documentation refinement for Parallel Scans
Next
From: Justin Pryzby
Date:
Subject: Re: GUC values - recommended way to declare the C variables?