Re: Upper limit arguments of pg_logical_slot_xxx_changes functionsaccept invalid values - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Upper limit arguments of pg_logical_slot_xxx_changes functionsaccept invalid values
Date
Msg-id 20181002044938.GT11712@paquier.xyz
Whole thread Raw
In response to Re: Upper limit arguments of pg_logical_slot_xxx_changes functionsaccept invalid values  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Tue, Aug 14, 2018 at 10:00:49AM +0900, Masahiko Sawada wrote:
> 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.

I don't link that we should change the existing behavior either which is
here for a couple of releases already, so let's mark the patch as
returned with feedback.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] get rid of StdRdOptions, use individual binaryreloptions representation for each relation kind instead
Next
From: Etsuro Fujita
Date:
Subject: Re: de-deduplicate code in DML execution hooks in postgres_fdw