Re: Pgoutput not capturing the generated columns - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Pgoutput not capturing the generated columns
Date
Msg-id CAA4eK1+wKxECWE1P4U=-ibMhis85j8FdtNL2gcDMvNMnpMof5w@mail.gmail.com
Whole thread Raw
In response to Re: Pgoutput not capturing the generated columns  (Peter Smith <smithpb2250@gmail.com>)
List pgsql-hackers
On Wed, Nov 6, 2024 at 11:35 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> I am observing some unexpected errors with the following scenario.
>

You are getting an expected ERROR. It is because of the design of
logical decoding which relies on historic snapshots.

> ======
> Tables:
>
> Publisher table:
> test_pub=# create table t1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
> CREATE TABLE
> test_pub=# insert into t1 values (1);
> INSERT 0 1
>
> ~
>
> And Subscriber table:
> test_sub=# create table t1(a int, b int);
> CREATE TABLE
>
> ======
> TEST PART 1.
>
> I create 2 publications, having different parameter values.
>
> test_pub=# create publication pub1 for table t1 with
> (publish_generated_columns=true);
> CREATE PUBLICATION
> test_pub=# create publication pub2 for table t1 with
> (publish_generated_columns=false);
> CREATE PUBLICATION
>
> ~
>
> And I try creating a subscription simultaneously subscribing to both
> of these publications. This fails with an expected error.
>
> test_sub=# create subscription sub1 connection 'dbname=test_pub'
> publication pub1, pub2;
> ERROR:  cannot use different column lists for table "public.t1" in
> different publications
>
> ======
> TEST PART 2.
>
> Now on publisher set parameter for pub2 to be true;
>
> test_pub=# alter publication pub2 set (publish_generated_columns);
> ALTER PUBLICATION
> test_pub=# \dRp+
>                                         Publication pub1
>   Owner   | All tables | Inserts | Updates | Deletes | Truncates | Via
> root | Genera
> ted columns
> ----------+------------+---------+---------+---------+-----------+----------+-------
> ------------
>  postgres | f          | t       | t       | t       | t         | f        | t
> Tables:
>     "public.t1"
>
>                                         Publication pub2
>   Owner   | All tables | Inserts | Updates | Deletes | Truncates | Via
> root | Genera
> ted columns
> ----------+------------+---------+---------+---------+-----------+----------+-------
> ------------
>  postgres | f          | t       | t       | t       | t         | f        | t
> Tables:
>     "public.t1"
>
> ~
>
> Now the create subscriber works OK.
>
> test_sub=# create subscription sub1 connection 'dbname=test_pub'
> publication pub1,pub2;
> NOTICE:  created replication slot "sub1" on publisher
> CREATE SUBSCRIPTION
>
> ======
> TEST PART 3.
>
> Now on Publisher let's alter that parameter back to false again...
>
> test_pub=# alter publication pub2 set (publish_generated_columns=false);
> ALTER PUBLICATION
>
> And insert some data.
>
> test_pub=# insert into t1 values (2);
> INSERT 0 1
>
> ~
>
> Now the subscriber starts failing again...
>
> ERROR:  cannot use different values of publish_generated_columns for
> table "public.t1" in different publications
> etc...
>
> ======
> TEST PART 4.
>
> Finally, on the Publisher alter that parameter back to true again!
>
> test_pub=# alter publication pub2 set (publish_generated_columns);
> ALTER PUBLICATION
...
>
>
> ~~
>
> Unfortunately, even though the publication parameters are the same
> again, the subscription seems to continue forever failing....
>
> ERROR:  cannot use different values of publish_generated_columns for
> table "public.t1" in different publications
>

The reason is that the failing 'insert' uses a historic snapshot,
which has a catalog state where 'publish_generated_columns' is still
false. So, you are seeing that error repeatedly. This behavior exists
from the very beginning of logical replication and another issue due
to the same reason was reported recently [1] which is actually a setup
issue. We should improve this situation some day but it is not the
responsibility of this patch.

[1] - https://www.postgresql.org/message-id/18683-a98f79c0673be358%40postgresql.org

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Pgoutput not capturing the generated columns
Next
From: jian he
Date:
Subject: can_partial_agg use root->processed_groupClause instead of parse->groupClause