Re: Test mail for pgsql-hackers
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t51223psql -h localhost -U postgresBuilt from patchset v2 (message #2), September 20, 2026 at 03:41 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t51223_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t51223_2 && git checkout t51223_2Patchset v2 (message #2) is on t51223_2
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
Show quoted text
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!
Thanks, Blessy
Attachments:
Datatype_mismatch_logicalreplication_.patchtext/x-patch; charset=US-ASCII; name=Datatype_mismatch_logicalreplication_.patchDownload+28-1
Import Notes
Reply to msg id not found: 174169564522.1026.2898870207896218165@malur.postgresql.orgReference msg id not found: 174169564522.1026.2898870207896218165@malur.postgresql.org
---------- Forwarded message ---------
From: BharatDB <bharatdbpg@gmail.com>
Date: Tue, Mar 11, 2025 at 6:03 PM
Subject: Re: Test mail for pgsql-hackers
To: pgsql-hackers Owner <pgsql-hackers-owner@lists.postgresql.org>, <
pgsql-hackers@lists.postgresql.org>, <pgsql-hackers@postgresql.org>
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
Show quoted text
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!
Thanks, Blessy
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.
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
On Wednesday, March 12, 2025, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
wrote:
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.
If there is really a patch submission happening here I suggest you start a
new thread with a meaningful subject line and proper recipients (one list,
not -owners)
David J.
