On Sun, Oct 4, 2026 at 2:01 AM Dilip Kumar <[email protected]> wrote:
>
> Here is the failed test case
>
> -- On Publisher:
> CREATE TABLE tab_temporal (
> id int4range,
> valid_at datemultirange,
> PRIMARY KEY (id, valid_at WITHOUT OVERLAPS)
> );
> INSERT INTO tab_temporal VALUES ('[1,2)', '{[2020-01-01,2021-01-01)}');
> CREATE PUBLICATION pub_temporal FOR TABLE tab_temporal;
>
> -- On Subscriber:
> CREATE TABLE tab_temporal (
> id int4range,
> valid_at datemultirange,
> PRIMARY KEY (id, valid_at WITHOUT OVERLAPS)
> );
> CREATE SUBSCRIPTION sub_temporal
> CONNECTION '...'
> PUBLICATION pub_temporal
> WITH (conflict_log_destination = 'table');
>
> -- After initial sync, delete the row locally on the subscriber:
> DELETE FROM tab_temporal;
>
> -- Then delete the row on the publisher to trigger a
> delete_missing conflict:
> DELETE FROM tab_temporal;
>
> And without fix shared as a v77-0003 [1], this would error out with
> below error[2], I have explained the reason [1].
>
Okay, I see the problem but I wonder why you didn't consider using
rd_opcintype stored in index relation to solve this problem. I have
tried the attached atop v79-0001 and v79-0002, manually executed the
test you shared in this email and it fixed the issue for me.
--
With Regards,
Amit Kapila.
diff --git a/src/backend/replication/logical/conflict.c
b/src/backend/replication/logical/conflict.c
index f0b71a74d89..a286f616f9c 100644
--- a/src/backend/replication/logical/conflict.c
+++ b/src/backend/replication/logical/conflict.c
@@ -1138,7 +1138,11 @@ build_index_key_json(EState *estate, Relation localrel,
continue;
}
- getTypeOutputInfo(att->atttypid, &outfuncoid,
&typisvarlena);
+ /*
+ * See BuildIndexValueDescription() for why we used
+ * rd_opcintype instead index's tupleDesc.
+ */
+ getTypeOutputInfo(indexDesc->rd_opcintype[i],
&outfuncoid, &typisvarlena);
outputstr = OidOutputFunctionCall(outfuncoid,
values[i]);
escape_json(&result, outputstr);
pfree(outputstr);