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
-
Add safeguards in LSN, numeric and float calculation for custom errors
- a76cfba663ce 13.0 landed
-
Don't call data type input functions in GUC check hooks
- 21f428ebde39 12.0 cited