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
-
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