On Mon, Apr 7, 2025 at 5:37 PM Amit Kapila wrote: > > On Wed, Mar 26, 2025 at 10:3 AM Zhijie Hou (Fujitsu) > <houzj.f...@fujitsu.com> wrote: > > > > On Wed, Feb 19, 2025 at 4:38 AM Tom Lane wrote: > > > > My colleague Nisha reported off-list about a crash in logical replication > > that > > occurs during unique constraint violations on leaf partitions. Upon > > investigation, I confirmed that this crash started happening after commit > > 9ff6867. > > > > Even though the commit 9ff68679b5 is backpatched to 17, the proposed > patch needs to be applied only for HEAD because the requirement for > additional conflict information is new to HEAD, right?
Right. > > > The problem arises because unique key conflict detection relied on the > > ExecOpenIndices call in apply_handle_insert_internal and > > apply_handle_tuple_routing with the speculative parameter set to true to > > construct necessary index information. However, these openings were > redundant, > > as indexes had already been opened during target partition searches via the > > parent table (e.g., using ExecFindPartition). Hence, they were removed in > > commit 9ff6867. Unfortunately, ExecFindPartition opens indexes without > > constructing the needed index information for conflict detection, which > > leads > > to the crash. > > > > To fix it, I tried to add a detect_conflict flag in ModifyTableState, > > enabling > > ExecFindPartition() to internally build the required index information in > > this > > case, like the attachment. > > > > I have a question about the additional information built in > ExecOpenIndices(). We built the required information when the index is > not used for exclusion constraint whereas we set the specConflict flag > in ExecInsertIndexTuples() even for the exclusion constraints case. > The specConflict flag is used by the caller to report conflicts. So, > won't we need to build the required information in ExecOpenIndices() > even when the index is used for exclusion constraint? I think the index information used for detecting exclusion conflict is always initialized In ExecOpenIndices-> BuildIndexInfo -> RelationGetExclusionInfo regardless of the input parameter. > What is the > behavior of conflict reporting code in case of exclusion constraints? Under logical replication context, since we do not detect conflicts for exclusion constraints, it would simply report the original constraint violation ERROR. Best Regards, Hou zj