BUG? Unpublished generated columns are reported "missing" by the subscription

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: BUG? Unpublished generated columns are reported "missing" by the subscription
Date: 2026-11-04 01:00:17
Message-ID: CAHut+Pu7CuuqSJNzXUXiBfhByd16j4JtLXeNEr=QtPMjjH02Rg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(This was discovered while investigating a similar topic [1]).

AFAIK generated columns should not normally be logically replicated:
- VIRTUAL gencols, never
- STORED gencols, according to the 'publish_generated_columns' parameter

So, why does the subscription tablesync complain below that the column
name "a" does not exist, given that it will not be replicated anyway?

For example, at the publisher-side

test_pub=# CREATE TABLE T_GENCOLS(a int generated always as (99) VIRTUAL);
CREATE TABLE
test_pub=# insert into t_gencols default values;
INSERT 0 1
test_pub=# insert into t_gencols default values;
INSERT 0 1
test_pub=# insert into t_gencols default values;
INSERT 0 1
test_pub=# select * from t_gencols;
a
----
99
99
99
(3 rows)
test_pub=# CREATE PUBLICATION pub1 FOR TABLE t_gencols;
CREATE PUBLICATION

Then, on the subscriber-side

test_sub=# create table t_gencols(local_col text default
'subscriber-gencol-default');
CREATE TABLE
test_sub=# create subscription sub1 connection 'dbname=test_pub'
publication pub1;
NOTICE: created replication slot "sub1" on publisher
CREATE SUBSCRIPTION
test_sub=#
2026-11-04 09:57:53.983 AEDT [345164] LOG: logical replication apply
worker for subscription "sub1" has started
2026-11-04 09:57:53.995 AEDT [345166] LOG: logical replication table
synchronization worker for subscription "sub1", table "t_gencols" has
started
2026-11-04 09:57:54.059 AEDT [345166] ERROR: logical replication
target relation "public.t_gencols" is missing replicated column: "a"

~~~

OTOH, when the subscription is created with parameter copy_data=false
then it works as expected for normal replication, therefore I suspect
this may be a tablesync-only problem, probably in function
fetch_remote_table_info() although I have not yet debugged/proved
that.

Thoughts?

======
[1] https://www.postgresql.org/message-id/flat/CAL5_ZS1bnYkK_GrA4N4SVKYgYsMMJxL9416m%3DvECAjrcwmQkkg%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Fittl 2026-11-04 01:19:00 Re: Assert failure in parallel query due to SubPlan double visit for hash join
Previous Message Lukas Fittl 2026-11-04 00:56:43 Re: Fix cumulative WAL statistics double-counting from parallel workers