(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
