On Fri, Mar 21, 2025 at 12:50 PM Nisha Moond wrote:
> Thanks, Hou-san, for the review and fix patches. I’ve incorporated
> your suggestions.
> Attached are the v7 patches, including patch 002, which implements
> stats collection for 'multiple_unique_conflicts' in
> pg_stat_subscription_stats.
On Thu, Mar 20, 2025 at 5:23 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thu, Mar 20, 2025 at 3:06 PM Nisha Moond wrote:
> >
> > Attached is v6 patch with above comments addressed.
>
> Thanks updating the patch. I have some comments:
>
> 1.
>
> The naming style of variables changed in this function seem
e the v8 patches.
[1]
https://www.postgresql.org/message-id/OS0PR01MB57169BA3CB76A79B30223E3894DB2%40OS0PR01MB5716.jpnprd01.prod.outlook.com
--
Thanks,
Nisha
From 008eef82c2fca1976883e8e2b50758ce6623f33b Mon Sep 17 00:00:00 2001
From: Nisha Moond
Date: Tue, 18 Mar 2025 12:27:48 +0530
Subject: [PA
Hi Nisha,
I saw this patch was already pushed [1], but there was one thing I
never quite understood about this feature, and I didn't find the
answer in the thread posts above.
My question: Why is there only a single new conflict type being added here?
e.g.
Conflict due to INSERT
- single confli
On Fri, Apr 4, 2025 at 10:41 AM Peter Smith wrote:
>
> My point is, if it is deemed useful for a user to know if a *single*
> conflict was caused by an INSERT or by an UPDATE, then why is it not
> equally useful to know if *multiple* conflicts were caused by an
> INSERT or by an UPDATE?
>
The rea
On Tue, Mar 25, 2025 at 8:51 AM vignesh C wrote:
>
> On Fri, 21 Mar 2025 at 16:44, Nisha Moond wrote:
> >
> > On Fri, Mar 21, 2025 at 3:38 PM Amit Kapila wrote:
> > >
> > > On Fri, Mar 21, 2025 at 1:48 PM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Fri, Mar 21, 2025 at 12:50 PM Nisha M
On Fri, 21 Mar 2025 at 16:44, Nisha Moond wrote:
>
> On Fri, Mar 21, 2025 at 3:38 PM Amit Kapila wrote:
> >
> > On Fri, Mar 21, 2025 at 1:48 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Fri, Mar 21, 2025 at 12:50 PM Nisha Moond wrote:
> > >
> > > > Thanks, Hou-san, for the review and fix pa
On Fri, Mar 21, 2025 at 4:43 PM Nisha Moond wrote:
>
> Attached are the v8 patches.
>
Thanks, the patches look good to me, so pushed.
--
With Regards,
Amit Kapila.
On Fri, Mar 21, 2025 at 1:48 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Fri, Mar 21, 2025 at 12:50 PM Nisha Moond wrote:
>
> > Thanks, Hou-san, for the review and fix patches. I’ve incorporated
> > your suggestions.
> > Attached are the v7 patches, including patch 002, which implements
> > stats collec
On Thu, Mar 20, 2025 at 3:06 PM Nisha Moond wrote:
>
> Attached is v6 patch with above comments addressed.
Thanks updating the patch. I have some comments:
1.
The naming style of variables changed in this function seems a bit Inconsistent
with existing ones, I feel we'd better use similar style
On Wed, Mar 19, 2025 at 4:18 PM Amit Kapila wrote:
>
> On Wed, Mar 19, 2025 at 11:11 AM Nisha Moond wrote:
> >
> > Please find the attached v5-0001 patch without the stats part.
> >
>
> Review:
> ===
> 1.
> + foreach_ptr(TupleTableSlot, slot, conflictSlots)
> + {
> + indexoid = lfirst_oid(lis
On Wed, Mar 19, 2025 at 11:11 AM Nisha Moond wrote:
>
> Please find the attached v5-0001 patch without the stats part.
>
Review:
===
1.
+ foreach_ptr(TupleTableSlot, slot, conflictSlots)
+ {
+ indexoid = lfirst_oid(list_nth_cell(conflictIndexes, conflictNum));
+
+ Assert(!OidIsValid(indexoid)
On Mon, Mar 17, 2025 at 3:20 PM Amit Kapila wrote:
>
> On Thu, Mar 13, 2025 at 4:30 PM Nisha Moond wrote:
> >
> > Attached is the v4 patch (test case changes only).
> >
>
> Comments:
> =
> 1.
> + /*
> + * Report an INSERT_EXISTS or UPDATE_EXISTS conflict when only one unique
> + * constra
On Thu, Mar 13, 2025 at 4:30 PM Nisha Moond wrote:
>
> Attached is the v4 patch (test case changes only).
>
Comments:
=
1.
+ /*
+ * Report an INSERT_EXISTS or UPDATE_EXISTS conflict when only one unique
+ * constraint is violated.
+ */
+ if (conflicts == 1)
+ {
+ Oid uniqueidx;
+ RepOrigi
Hi,
For v3, CFbot failed for the patch test case due to unstable test
steps. Truncating the subscriber table resolved the apply worker error
but sometimes caused out-of-order inserts, leading to unexpected
failures instead of a conflict error. Fixed this and updated the LOG
regex check to avoid fa
On Wed, Mar 12, 2025 at 6:33 AM Peter Smith wrote:
>
> Hi Nisha,
>
> Thanks for addressing some of my v1 comments. I confirmed they are all
> ok. But, I haven't reviewed the v2 again because I still had doubts
> about the "stats" question and am waiting to see how that pans out.
> Meanwhile, I ha
On Tue, Mar 11, 2025 at 2:28 PM Nisha Moond wrote:
>
> On Tue, Mar 11, 2025 at 11:10 AM Dilip Kumar wrote:
> The goal of introducing a new conflict type is to handle multiple-key
> conflicts separately. It will not only allow users to apply different
> resolution methods for single-key vs multi-
Hi Nisha,
Thanks for addressing some of my v1 comments. I confirmed they are all
ok. But, I haven't reviewed the v2 again because I still had doubts
about the "stats" question and am waiting to see how that pans out.
Meanwhile, I had a couple more replies below.
On Tue, Feb 25, 2025 at 8:37 PM N
On Tue, Mar 11, 2025 at 11:10 AM Dilip Kumar wrote:
>
> On Thu, Feb 20, 2025 at 5:01 PM Nisha Moond wrote:
> >
> > Hi Hackers,
> > (CCing people involved in related discussions)
> >
> > I am starting this thread to propose a new conflict detection type
> > "multiple_unique_conflicts" that identif
On Thu, Feb 20, 2025 at 5:01 PM Nisha Moond wrote:
>
> Hi Hackers,
> (CCing people involved in related discussions)
>
> I am starting this thread to propose a new conflict detection type
> "multiple_unique_conflicts" that identifies when an incoming row
> during logical replication violates more t
On Mon, Feb 24, 2025 at 7:39 AM Peter Smith wrote:
>
> Hi Nisha.
>
> Some review comments for patch v1-0001
>
> ==
> GENERAL
>
> 1.
> This may be a basic/naive question, but it is unclear to me why we
> care about the stats of confl_multiple_unique_conflicts?
>
> I can understand it would be u
Hi Nisha.
Some review comments for patch v1-0001
==
GENERAL
1.
This may be a basic/naive question, but it is unclear to me why we
care about the stats of confl_multiple_unique_conflicts?
I can understand it would be useful to get multiple conflicts logged
at the same time so the user doesn'
Hi Hackers,
(CCing people involved in related discussions)
I am starting this thread to propose a new conflict detection type
"multiple_unique_conflicts" that identifies when an incoming row
during logical replication violates more than one UNIQUE constraint.
If multiple constraints (such as the p
23 matches
Mail list logo
