Re: logical replication restrictions - Mailing list pgsql-hackers

From Melih Mutlu
Subject Re: logical replication restrictions
Date
Msg-id CAGPVpCQgE1e0JQFHbxSpfj82HQfAqGmhG=yru3mX2tcmbfqHYA@mail.gmail.com
Whole thread Raw
In response to Re: logical replication restrictions  ("Euler Taveira" <euler@eulerto.com>)
Responses Re: logical replication restrictions
List pgsql-hackers
Hi Euler,

I've some comments/questions about the latest version (v4) of your patch.

Firstly, I think the patch needs a rebase. CI currently cannot apply it [1].

22. src/test/subscription/t/032_apply_delay.pl

I received the following error when trying to run these 'subscription' tests:

t/032_apply_delay.pl ............... No such class log_location at
t/032_apply_delay.pl line 49, near "my log_location"
syntax error at t/032_apply_delay.pl line 49, near "my log_location ="

I'm having these errors too. Seems like some declarations are missing.


+          specified amount of time. If this value is specified without units,
+          it is taken as milliseconds. The default is zero, adding no delay.
+         </para>
I'm also having an issue when I give min_apply_delay parameter without units.
I expect that if I set  min_apply_delay to 5000 (without any unit), it will be interpreted as 5000 ms.

I tried:
postgres=# CREATE SUBSCRIPTION testsub CONNECTION 'dbname=postgres port=5432' PUBLICATION testpub WITH (min_apply_delay=5000);

And logs showed:
2022-07-13 20:26:52.231 +03 [5422] LOG:  logical replication apply delay: 4999999 ms
2022-07-13 20:26:52.231 +03 [5422] CONTEXT:  processing remote data for replication origin "pg_18126" during "BEGIN" in transaction 3152 finished at 0/465D7A0

Looks like it starts from 5000000 ms instead of 5000 ms for me. If I state the unit as ms, then it works correctly.
 

Lastly, I have a question about this delay during tablesync. 
It's stated here that apply delays are not for initial tablesync.

 <para>
+          The delay occurs only on WAL records for transaction begins and after
+          the initial table synchronization. It is possible that the
+          replication delay between publisher and subscriber exceeds the value
+          of this parameter, in which case no delay is added. Note that the
+          delay is calculated between the WAL time stamp as written on
+          publisher and the current time on the subscriber. Delays in logical
+          decoding and in transfer the transaction may reduce the actual wait
+          time. If the system clocks on publisher and subscriber are not
+          synchronized, this may lead to apply changes earlier than expected.
+          This is not a major issue because a typical setting of this parameter
+          are much larger than typical time deviations between servers.
+         </para>

There might be a case where tablesync workers are in SYNCWAIT state and waiting for apply worker to tell them to CATCHUP. 
And if apply worker is waiting in apply_delay function, tablesync workers will be stuck at SYNCWAIT state and this might delay tablesync at least "min_apply_delay" amount of time or more.
Is it something we would want? What do you think?




Best,
Melih

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: fix stats_fetch_consistency value in postgresql.conf.sample
Next
From: Tom Lane
Date:
Subject: Re: make update-po@master stops at pg_upgrade