Thread: Re: Test mail for pgsql-hackers

Hi Blessy,

On Tue, Mar 11, 2025 at 6:03 PM BharatDB <bharatdbpg@gmail.com> wrote:
>>
>> Hi ,
>
>
>>
>> I’ve been exploring logical replication and noticed that if the column datatypes don’t match between the publisher
andsubscriber, PostgreSQL doesn’t give a warning. This can cause unexpected behavior, and I thought it might be helpful
toalert 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
pointingout 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—pleaselet 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

Hi Blessy,

On Tue, Mar 11, 2025 at 6:03 PM BharatDB <bharatdbpg@gmail.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.