Re: Test mail for pgsql-hackers

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: BharatDB <bharatdbpg(at)gmail(dot)com>
Cc: pgsql-hackers Owner <pgsql-hackers-owner(at)lists(dot)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Test mail for pgsql-hackers
Date: 2025-03-12 10:26:08
Message-ID: CAExHW5t=VfgmdqMCJDh=j5K_7zGhaLNBRZ2SiWxagAVG2XL7+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hi Blessy,

On Tue, Mar 11, 2025 at 6:03 PM BharatDB <bharatdbpg(at)gmail(dot)com> wrote:
>>
>> Hi ,
>
>
>>
>> I’ve been exploring logical replication and noticed that if the column datatypes don’t match between the publisher and subscriber, PostgreSQL doesn’t give a warning. This can cause unexpected behavior, and I thought it might be helpful to alert users when this happens.
>
>
>>
>> ### **What This Patch Does:**
>
>
>>
>> - Adds a warning when a column's datatype in the subscriber doesn’t match the publisher.
>>
>> - Helps users catch issues early instead of running into silent errors later.
>
>
>>
>> Why I Think It’s Useful:- Avoids confusion when replication doesn’t work as expected. - Makes debugging easier by pointing out potential problems. I’d love to get feedback on whether this is a good idea and if I’ve approached it correctly. Since I’m still learning, any suggestions for improvement would be really helpful. I’ve attached the patch—please let me know what you think!

Large part of your patch is renaming files which are not related to
this patch. Can you please clean that up.

The code also looks problematic
+ Oid local_typid = TupleDescAttr(tupdesc, i)->atttypid;
+ Oid remote_typid = lrel.atttyps[i];

AFAIK, the attribute positions on the publisher and subscriber need
not match, but this code assumes that the attributes at ith position
on publisher has to be mapped to the attribute at the same position on
the subscriber.

+
+ /* Get human-readable type names */
+ char *local_typname = format_type_be(local_typid);
+ char *remote_typname = format_type_be(remote_typid);

format_type_be() will give the name of the type on the subscriber not
on the publisher. You will need to look up logical replication type
cache for the name of the type on remote. If further assumes that the
OIDs on the same types on the publisher and the subscriber are same,
which may not be.

My memory is hazy as to whether we consider the types with the same
name on publisher and subscriber to be equivalent. If not, then I see
no way to make sure that the mapped columns are of the same type.

--
Best Wishes,
Ashutosh Bapat

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Langote 2025-03-12 12:24:09 Re: BUG #18830: ExecInitMerge Segfault on MERGE
Previous Message Dean Rasheed 2025-03-12 10:16:13 Re: Attribute of type record has wrong type error with MERGE ... WHEN NOT MATCHED BY SOURCE THEN DELETE

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2025-03-12 10:26:46 Re: meson vs. llvm bitcode files
Previous Message Rushabh Lathia 2025-03-12 10:22:38 Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints