From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Upper limit arguments of pg_logical_slot_xxx_changes functions accept invalid values |
Date: | 2018-07-27 17:00:18 |
Message-ID: | CA+TgmobS9r2a3uLq6_xUP-LjZXWqbsE=MGUR2pDCv+FSbc_8PQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 11, 2018 at 8:58 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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 am not prepared to spend much time arguing about it, but I think we
should just leave this the way it is.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-07-27 17:01:40 | Re: How can we submit code patches that implement our (pending) patents? |
Previous Message | Robert Haas | 2018-07-27 16:51:17 | Re: Deprecating, and scheduling removal of, pg_dump's tar format. |