On Sunday, March 21, 2021 4:40 PM Amit Kapila wrote:
>I have enhanced the patch for 2PC implementation on the
>subscriber-side as per the solution discussed here [1].
FYI.
I did the confirmation for the solution of unique GID problem raised at [1].
This problem in V61-patches at [2] is fixed in
On Sun, Mar 21, 2021 at 2:47 PM Markus Wanner
wrote:
>
> On 20.03.21 16:14, Amit Kapila wrote:
> > Right, but I guess in our case using user-provided GID will conflict
> > if we use multiple subscriptions on the same node. So, it is better to
> > generate a unique identifier like we are discussing
On 20.03.21 16:14, Amit Kapila wrote:
Right, but I guess in our case using user-provided GID will conflict
if we use multiple subscriptions on the same node. So, it is better to
generate a unique identifier like we are discussing here, something
like (origin_id of subscription + xid of the publis
On Sat, Mar 20, 2021 at 8:53 PM Amit Kapila wrote:
>
> On Sat, Mar 20, 2021 at 4:02 PM Dilip Kumar wrote:
> >
> > On Sat, Mar 20, 2021 at 7:50 AM Amit Kapila wrote:
> > >
> > > On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner
> > > wrote:
> >
> > > So, I think you are using xid of publisher and or
On Sat, Mar 20, 2021 at 4:02 PM Dilip Kumar wrote:
>
> On Sat, Mar 20, 2021 at 7:50 AM Amit Kapila wrote:
> >
> > On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner
> > wrote:
>
> > So, I think you are using xid of publisher and origin_id of
> > subscription to achieve uniqueness because both will be
On Sat, Mar 20, 2021 at 2:57 PM Markus Wanner
wrote:
>
> On 20.03.21 03:17, Amit Kapila wrote:
> > Are you saying that users might use the same GID which we have
> > constructed internally (say by combining origin and xid: originid_xid)
> > and then there will be conflict while replaying such tran
On Sat, Mar 20, 2021 at 7:50 AM Amit Kapila wrote:
>
> On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner
> wrote:
> So, I think you are using xid of publisher and origin_id of
> subscription to achieve uniqueness because both will be accessible in
> prepare and commit prepared. Right? If so, I think
On 20.03.21 03:17, Amit Kapila wrote:
Are you saying that users might use the same GID which we have
constructed internally (say by combining origin and xid: originid_xid)
and then there will be conflict while replaying such transactions?
No, I was pondering about a user doing (in short sequenc
On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner
wrote:
>
> On 18.03.21 10:45, Amit Kapila wrote:
> > While reviewing/testing subscriber-side work for $SUBJECT [1], I
> > noticed a problem that seems to need a broader discussion, so started
> > this thread. We can get prepare for the same GID more th
On 18.03.21 10:45, Amit Kapila wrote:
While reviewing/testing subscriber-side work for $SUBJECT [1], I
noticed a problem that seems to need a broader discussion, so started
this thread. We can get prepare for the same GID more than once for
the cases where we have defined multiple subscriptions f
On Thu, Mar 18, 2021 at 8:46 PM Amit Kapila wrote:
>
>
> However, if the user has setup synchronous_standby_names for all the
> subscriptions then we won't be able to proceed because the prepare on
> publisher will wait for all the subscriptions to ack and the
> subscriptions are waiting for the
On Thu, Mar 18, 2021 at 5:31 PM vignesh C wrote:
>
> On Thu, Mar 18, 2021 at 3:16 PM Amit Kapila wrote:
> >
> >
> > In short, on the subscriber, both the apply workers (corresponding to
> > two subscriptions) are getting the same prepare transaction GID,
> > leading to an error on the subscriber
On Thu, Mar 18, 2021 at 3:16 PM Amit Kapila wrote:
>
> While reviewing/testing subscriber-side work for $SUBJECT [1], I
> noticed a problem that seems to need a broader discussion, so started
> this thread. We can get prepare for the same GID more than once for
> the cases where we have defined mu
13 matches
Mail list logo
