Обсуждение: ALTER SUBSCRIPTION REFRESH PUBLICATION has default copy_data = true?

Hi.

The documentation of ALTER SUBSCRIPTION REFRESH PUBLICATION [1] says:

----------

REFRESH PUBLICATION

Fetch missing table information from publisher. This will start
replication of tables that were added to the subscribed-to
publications since the last invocation of REFRESH PUBLICATION or since
CREATE SUBSCRIPTION.

refresh_option specifies additional options for the refresh operation.
The supported options are:

copy_data (boolean)

Specifies whether the existing data in the publications that are being
subscribed to should be copied once the replication starts. The
default is true. (Previously subscribed --tables are not copied.)

----------

But I found that default copy_data = true to be unintuitive.

e.g. When I had previously done the CREATE SUBSCRIPTION using
copy_data = false, then I assumed (wrongly) that the subscription
default would remain as copy_data = false even when doing the REFRESH
PUBLICATION.

Is that a deliberate functionality, or is it a quirk / bug?

------
[1] https://www.postgresql.org/docs/devel/sql-altersubscription.html

Kind Regards,
Peter Smith.
Fujitsu Australia

On 02.06.21 03:10, Peter Smith wrote:
> The documentation of ALTER SUBSCRIPTION REFRESH PUBLICATION [1] says:

> But I found that default copy_data = true to be unintuitive.
> 
> e.g. When I had previously done the CREATE SUBSCRIPTION using
> copy_data = false, then I assumed (wrongly) that the subscription
> default would remain as copy_data = false even when doing the REFRESH
> PUBLICATION.
> 
> Is that a deliberate functionality, or is it a quirk / bug?

copy_data is an option of the action, not a property of the 
subscription.  The difference between those two things is admittedly not 
  clearly (at all?) documented.

However, I'm not sure whether creating a subscription that always 
defaults to copy_data=false for tables added in the future is useful 
functionality, so I think the current behavior is okay.

On Wed, Jun 2, 2021 at 6:40 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> Hi.
>
> The documentation of ALTER SUBSCRIPTION REFRESH PUBLICATION [1] says:
>
> ----------
>
> REFRESH PUBLICATION
>
> Fetch missing table information from publisher. This will start
> replication of tables that were added to the subscribed-to
> publications since the last invocation of REFRESH PUBLICATION or since
> CREATE SUBSCRIPTION.
>
> refresh_option specifies additional options for the refresh operation.
> The supported options are:
>
> copy_data (boolean)
>
> Specifies whether the existing data in the publications that are being
> subscribed to should be copied once the replication starts. The
> default is true. (Previously subscribed --tables are not copied.)
>
> ----------
>
> But I found that default copy_data = true to be unintuitive.
>
> e.g. When I had previously done the CREATE SUBSCRIPTION using
> copy_data = false, then I assumed (wrongly) that the subscription
> default would remain as copy_data = false even when doing the REFRESH
> PUBLICATION.

The fact is that the options copy_data, create_slot and connect are
not stored in the catalog pg_subscription (actually they don't need to
be). Among these the copy_data option can be specified in the ALTER
... SUBSCRIPTION.

> Is that a deliberate functionality, or is it a quirk / bug?

I don't think it's a bug. Maybe adding a note in the docs about the
options which are stored/not stored in the pg_subscription catalog
would help.

With Regards,
Bharath Rupireddy.

On Thu, Jun 3, 2021 at 12:52 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> > Is that a deliberate functionality, or is it a quirk / bug?
>
> copy_data is an option of the action, not a property of the
> subscription.  The difference between those two things is admittedly not
>   clearly (at all?) documented.
>
> However, I'm not sure whether creating a subscription that always
> defaults to copy_data=false for tables added in the future is useful
> functionality, so I think the current behavior is okay.

...

On Thu, Jun 3, 2021 at 12:53 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> > Is that a deliberate functionality, or is it a quirk / bug?
>
> I don't think it's a bug....

...

OK. Thanks to both of you for sharing your thoughts about it.

------
Kind Regards,
Peter Smith
Fujitsu Australia