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 по дате отправления: