Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value - Mailing list pgsql-general

From Tom Lane
Subject Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value
Date
Msg-id 1138318.1636473982@sss.pgh.pa.us
Whole thread Raw
In response to Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Tue, Nov 9, 2021 at 7:50 AM Avi Weinberg <AviW@gilat.com> wrote:
>> Was this done on purpose, that default value for new column is not copied
>> for existing data?  Does this mean that on destination side we must also
>> define the table with default value?

> If you run a command on the publisher that causes every row to change then
> of course every row will be published with those new values to the
> subscriber.

I think the important point here is that the ALTER ADD COLUMN operation
*didn't* cause a physical update of every row on the publisher, thus
nothing got sent to the subscriber.

This is sort of annoying, because it is making what ought to be a purely
internal optimization user-visible.  Depending on the details of the
column default (is it null, is it a constant) and which PG version you
are talking about, there may or may not be a rewrite of the source table,
and here we see that that is semantically visible to subscribers.

I don't want to give up the aforesaid optimization --- it's a feature that
you can do common forms of ALTER ADD COLUMN in O(1) time.  But maybe we
ought to document the implications for logical replication better.

            regards, tom lane



pgsql-general by date:

Previous
From: Avi Weinberg
Date:
Subject: RE: Logical Replication - Should Destination Table Columns Be Defined With Default Value
Next
From: Mark Dilger
Date:
Subject: Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value