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-08-01T08:21:13Z
Lists: pgsql-hackers
On Thu, Aug 01, 2019 at 12:39:26PM +0530, Jeevan Ladhe wrote:
> Here is a patch that takes care of addressing the flag issue including
> pg_lsn_in_internal() and others.
Your original patch for pg_lsn_in_internal() was right IMO, and the
new one is not. In the numeric and float code paths, we have this
kind of pattern:
if (have_error)
{
*have_error = true;
return;
}
else
elog(ERROR, "Boom. Show is over.");
But the pg_lsn.c portion does not have that. have_error cannot be
NULL or the caller may fall into the trap of setting it to NULL and
miss some errors at parsing-time. So I think that keeping the
assertion on (have_error != NULL) is necessary.
--
Michael
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