Re: Pgoutput not capturing the generated columns
Peter Smith <smithpb2250@gmail.com>
On Mon, Nov 4, 2024 at 12:28 AM vignesh C <vignesh21@gmail.com> wrote:
>
> On Thu, 31 Oct 2024 at 16:44, Ajin Cherian <itsajin@gmail.com> wrote:
> >
> >
> >
> > On Thu, Oct 31, 2024 at 9:55 PM Ajin Cherian <itsajin@gmail.com> wrote:
> >>
> >> I ran some tests and verified that the patch works with previous versions of PG12 and PG17
> >> 1. Verified with publications with generated columns and without generated columns on patched code and subscriptions on PG12 and PG17
> >> Observations:
> >> a. If publication is created with publish_generated_columns=true or with generated columns mentioned explicitly, then tablesync will not copy generated columns but post tablesync the generated columns are replicated
> >> b. Column list override (publish_generated_columns=false) behaviour
> >>
> >> These seem expected.
> >>
> >
> > Currently the documentation does not talk about this behaviour, I suggest this be added similar to how such a behaviour was documented when the original row-filter version was committed.
> > Suggestion:
> > "If a subscriber is a pre-18 version, the initial table synchronization won't publish generated columns even if they are defined in the publisher."
>
> The updated patch has the changes for the same.
Hi Vignesh,
Thanks for the latest doc v2 "fix" patch. Here are my review comments about it.
======
src/sgml/logical-replication.sgml
1.
During initial data synchronization, only the published columns are
copied. However, if the subscriber is from a release prior to 15, then
all the columns in the table are copied during initial data synchronization,
- ignoring any column lists.
+ ignoring any column lists. If the subscriber is from a release prior to 18,
+ then initial table synchronization won't copy generated columns data even if
+ they are defined in the publisher.
There are some inconsistencies with the markup etc.
a) For publication row filters the text about Initial Synchronization
version differences is using SGML <Note> markup. But, for "Column
Lists" the similar text about Initial Synchronization version
differences is just plain paragraph text. So, shouldn't this also be
using a <Note> markup for better documentation consistency?
b) I also thought "even if they are defined in the publisher" wording
seems like it is referring about the table definition, but IMO it
needs to convey something more like "even when they are published"
SUGGESTION
If the subscriber is from a release prior to 18, copy pre-existing
data does not copy generated columns even when they are published.
This is because old releases ignore generated table data during the
copy.
~~
Furthermore, we will have to write something more about this in the
main patch still being developed, because the same initial sync caveat
is true even for publication of generated columns published *without*
column lists.
======
Kind Regards,
Peter Smith.
Fujitsu Australia
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Generated column replication.
- 6252b1eaf82b 18.0 landed
-
Rename pubgencols_type to pubgencols in pg_publication.
- 75eb9766ec20 18.0 landed
-
Doc: Fix column name in pg_publication catalog.
- 117f9f328e0f 18.0 landed
-
Fix buildfarm failure introduced by commit e65dbc9927.
- b35434b134b1 18.0 landed
-
Change publication's publish_generated_columns option type to enum.
- e65dbc9927fb 18.0 landed
-
Fix \dRp+ output when describing publications with a lower server version.
- 991974bb4888 18.0 landed
-
Replicate generated columns when 'publish_generated_columns' is set.
- 7054186c4ebe 18.0 landed
-
Doc: Update the behavior of generated columns in Logical Replication.
- 5b0c46ea0932 18.0 landed
-
Replicate generated columns when specified in the column list.
- 745217a051a9 18.0 landed
-
Doc: Generated columns are skipped for logical replication.
- 7a089f6e6a14 17.0 cited