Re: concerns around pg_lsn
Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>
From: Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2019-07-31T11:56:42Z
Lists: pgsql-hackers
On Tue, Jul 30, 2019 at 6:06 PM Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Jul 30, 2019 at 4:52 AM Jeevan Ladhe > <jeevan.ladhe@enterprisedb.com> wrote: > > My only concern was something that we internally treat as invalid, why do > > we allow, that as a valid value for that type. While I am not trying to > > reinvent the wheel here, I am trying to understand if there had been any > > idea behind this and I am missing it. > > Well, the word "invalid" can mean more than one thing. Something can > be valid or invalid depending on context. I can't have -2 dollars in > my wallet, but I could have -2 dollars in my bank account, because the > bank will allow me to pay out slightly more money than I actually have > on the idea that I will pay them back later (and with interest!). So > as an amount of money in my wallet, -2 is invalid, but as an amount of > money in my bank account, it is valid. > > 0/0 is not a valid LSN in the sense that (in current releases) we > never write a WAL record there, but it's OK to compute with it. > Subtracting '0/0'::pg_lsn seems useful as a way to convert an LSN to > an absolute byte-index in the WAL stream. > Thanks Robert for such a nice and detailed explanation. I now understand why LSN '0/0' can still be useful. 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