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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
