RE: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From houzj.fnst@fujitsu.com
Subject RE: Skipping logical replication transactions on subscriber side
Date
Msg-id OS0PR01MB5716FE4FA3AF59AA5735FDD0949B9@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Skipping logical replication transactions on subscriber side
List pgsql-hackers
On Tuesday, November 16, 2021 2:31 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> Right. I've fixed this issue and attached an updated patch.
> 
Hi,

I have few comments for the testcases.

1)

+my $appname = 'tap_sub';
+$node_subscriber->safe_psql(
+    'postgres',
+    "CREATE SUBSCRIPTION tap_sub CONNECTION '$publisher_connstr application_name=$appname' PUBLICATION tap_pub WITH
(streaming= off, two_phase = on);");
 
+my $appname_streaming = 'tap_sub_streaming';
+$node_subscriber->safe_psql(
+    'postgres',
+    "CREATE SUBSCRIPTION tap_sub_streaming CONNECTION '$publisher_connstr application_name=$appname_streaming'
PUBLICATIONtap_pub_streaming WITH (streaming = on, two_phase = on);");
 
+

I think we can remove the 'application_name=$appname', so that the command
could be shorter. 

2)
+...(streaming = on, two_phase = on);");
Besides, is there some reasons to set two_phase to ? If so,
It might be better to add some comments about it.


3)
+CREATE PUBLICATION tap_pub_streaming FOR TABLE test_tab_streaming;
+]);
+

It seems there's no tests to use the table test_tab_streaming. I guess this
table is used to test streaming change error, maybe we can add some tests for
it ?

Best regards,
Hou zj

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: wait event and archive_command
Next
From: "Andrey V. Lepikhov"
Date:
Subject: Re: Global snapshots