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 TYCPR01MB83733A735773393E8878D935ED1C9@TYCPR01MB8373.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Time delayed LR (WAS Re: logical replication restrictions)  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses RE: Time delayed LR (WAS Re: logical replication restrictions)
List pgsql-hackers
Hi,


On Friday, December 9, 2022 3:38 PM Kuroda, Hayato/黒田 隼人 <kuroda.hayato@fujitsu.com> wrote:
> Thanks for reporting! I have analyzed the problem and found the root cause.
>
> This feature seemed not to work on 32-bit OSes. This was because the
> calculation of delay_time was wrong. The first argument of this should be
> TimestampTz datatype, not Datum:
>
> ```
> +       /* Set apply delay */
> +       delay_until =
> TimestampTzPlusMilliseconds(TimestampTzGetDatum(ts),
> +
> + MySubscription->applydelay);
> ```
>
> In more detail, the datum representation of int64 contains the value itself on
> 64-bit OSes, but it contains the pointer to the value on 32-bit.
>
> After modifying the issue, this will work on 32-bit environments.
Thank you for your analysis.

Yeah, it seems we conduct addition of values to the pointer value,
which is returned from the call of TimestampTzGetDatum(), on 32-bit machine
by mistake.

I'll remove the call in my next version.



Best Regards,
    Takamichi Osumi




pgsql-hackers by date:

Previous
From: Reid Thompson
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Next
From: Tom Lane
Date:
Subject: Re: Error-safe user functions