Re: Upper limit arguments of pg_logical_slot_xxx_changes functionsaccept invalid values
От | Masahiko Sawada |
---|---|
Тема | Re: Upper limit arguments of pg_logical_slot_xxx_changes functionsaccept invalid values |
Дата | |
Msg-id | CAD21AoDLKjC_dBh1UR6808oqm0kBNbTC9Jz_fM4jp0VZPuYrfg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Upper limit arguments of pg_logical_slot_xxx_changes functionsaccept invalid values (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Upper limit arguments of pg_logical_slot_xxx_changes functionsaccept invalid values
|
Список | pgsql-hackers |
On Sat, Jul 28, 2018 at 2:00 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jul 11, 2018 at 8:58 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >> While reading the replication slot codes, I found a wrong assignment >> in pg_logical_slot_get_changes_guts() function as follows. >> >> if (PG_ARGISNULL(2)) >> upto_nchanges = InvalidXLogRecPtr; >> else >> upto_nchanges = PG_GETARG_INT32(2); >> >> Since the upto_nchanges is an integer value we should set 0 meaning >> unlimited instead of InvalidXLogRecPtr. Since InvalidXLogRecPtr is >> actually 0 this function works fine so far. > > If somebody changes InvalidXLogRecPtr to (uint64)-1, then it breaks as > the code is written. On the other hand, if somebody reverted > 0ab9d1c4b31622e9176472b4276f3e9831e3d6ba, it would keep working as > written but break under your proposal. I might be missing something but I think the setting either 0 or negative values to it solves this problem. Since the upto_nchanges is int32 we cannot build if somebody reverted 0ab9d1c4b31622e9176472b4276f3e9831e3d6ba. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: