Re: concerns around pg_lsn

Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>

From: Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2019-08-01T05:59:54Z
Lists: pgsql-hackers
Hi Michael,

What is more dangerous with float8in_internal_opt_error() is, it has
> the have_error flag, which is never ever set or used in that function.
> Further
> more risks are - the callers of this function e.g.
> executeItemOptUnwrapTarget()
> are passing a non-null pointer to it(default set to false) and expect to
> throw
> an error if it sees some error during float8in_internal_opt_error(), *but*
> float8in_internal_opt_error() has actually never touched the have_error
> flag.
>

My bad, I see there's this macro call in float8in_internal_opt_error() and
that
set the flag:

{code}
#define RETURN_ERROR(throw_error) \
do { \
    if (have_error) { \
        *have_error = true; \
        return 0.0; \
    } else { \
        throw_error; \
    } \
} while (0)
{code}

My patch on way, thanks.

Regards,
Jeevan Ladhe

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