| 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?
Kind Regards,
Peter Smith.
Fujitsu Australia
| 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 |