Re: concerns around pg_lsn

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>
Cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2019-07-31T00:51:30Z
Lists: pgsql-hackers
On Tue, Jul 30, 2019 at 02:22:30PM +0530, Jeevan Ladhe wrote:
> On Tue, Jul 30, 2019 at 9:42 AM Michael Paquier <michael@paquier.xyz> wrote:
>> Agreed about making the code more defensive as you do.  I would keep
>> the initialization in check_recovery_target_lsn and pg_lsn_in_internal
>> though.  That does not hurt and makes the code easier to understand,
>> aka we don't expect an error by default in those paths.
>>
> 
> Sure, understood. I am ok with this.

I am adding Peter Eisentraut in CC as 21f428e is his commit.  I think
that the first patch is a good idea, so I would be fine to apply it,
but let's see the original committer's opinion first.
--
Michael

Commits

  1. Add safeguards in LSN, numeric and float calculation for custom errors

  2. Don't call data type input functions in GUC check hooks