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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Copy function for logical replication slots