Re: Pgoutput not capturing the generated columns

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Ajin Cherian <itsajin@gmail.com>, Shubham Khanna <khannashubham1197@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Rajendra Kumar Dangwal <dangwalrajendra888@gmail.com>, pgsql-hackers@lists.postgresql.org, euler@eulerto.com
Date: 2024-11-04T05:26:22Z
Lists: pgsql-hackers
On Mon, Nov 4, 2024 at 10:30 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Mon, Nov 4, 2024 at 12:28 AM vignesh C <vignesh21@gmail.com> wrote:
>
> 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?
>

I don't think both are comparable as the row filters section has a
separate sub-section for Initial Data Synchronization. In general, I
find the way things are described in the Column Lists sub-section more
like other parts of the documentation. Moreover, this patch has just
extended the existing docs.

> 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.
>

The second line says something obvious and doesn't seem to be
required. The change "even when they are published" is debatable as I
didn't read the way you read Vignesh's proposed wording, to me it was
clear what the doc is saying. I have already pushed Vignesh's version
with a minor modification.

-- 
With Regards,
Amit Kapila.



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Doc: Generated column replication.

  2. Rename pubgencols_type to pubgencols in pg_publication.

  3. Doc: Fix column name in pg_publication catalog.

  4. Fix buildfarm failure introduced by commit e65dbc9927.

  5. Change publication's publish_generated_columns option type to enum.

  6. Fix \dRp+ output when describing publications with a lower server version.

  7. Replicate generated columns when 'publish_generated_columns' is set.

  8. Doc: Update the behavior of generated columns in Logical Replication.

  9. Replicate generated columns when specified in the column list.

  10. Doc: Generated columns are skipped for logical replication.