Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value
Дата
Msg-id 1138318.1636473982@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Avi Weinberg
Дата:
Сообщение: RE: Logical Replication - Should Destination Table Columns Be Defined With Default Value
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value