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
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 for
publications on the same server and p
14 matches
Mail list logo
