Re: Time delayed LR (WAS Re: logical replication restrictions) - Mailing list pgsql-hackers

From Takamichi Osumi (Fujitsu)
Subject Re: Time delayed LR (WAS Re: logical replication restrictions)
Date
Msg-id TYCPR01MB83736C80098C9E284A550B20EDC59@TYCPR01MB8373.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: logical replication restrictions  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Hi, Horiguchi-san and Amit-san


On Wednesday, November 9, 2022 3:41 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
> Using interval is not standard as this kind of parameters but it seems
> convenient. On the other hand, it's not great that the unit month introduces
> some subtle ambiguity.  This patch translates a month to 30 days but I'm not
> sure it's the right thing to do. Perhaps we shouldn't allow the units upper than
> days.
In the past discussion, we talked about the merits to utilize the interval type.
On the other hand, now we are facing some incompatibility issues of parsing
between this time-delayed feature and physical replication's recovery_min_apply_delay.

For instance, the interval type can accept '600 m s h', '1d 10min' and '1m',
but the recovery_min_apply_delay makes the server failed to start by all of those.

Therefore, this would confuse users and I'm going to make the feature's input
compatible with recovery_min_apply_delay in the next version.


Best Regards,
    Takamichi Osumi




pgsql-hackers by date:

Previous
From: Egor Chindyaskin
Date:
Subject: Re: Stack overflow issue
Next
From: Masahiko Sawada
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply