RE: Time delayed LR (WAS Re: logical replication restrictions)
| От | Takamichi Osumi (Fujitsu) |
|---|---|
| Тема | RE: Time delayed LR (WAS Re: logical replication restrictions) |
| Дата | |
| Msg-id | TYCPR01MB83733A735773393E8878D935ED1C9@TYCPR01MB8373.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | RE: Time delayed LR (WAS Re: logical replication restrictions) ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
| Ответы |
RE: Time delayed LR (WAS Re: logical replication restrictions)
|
| Список | 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 по дате отправления: