Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)
От | Robert Haas |
---|---|
Тема | Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485) |
Дата | |
Msg-id | CA+TgmobmNsHeE5tV=MVR3A9apQkkTxMqjfEi=529R+ih-HH9rg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, May 31, 2022 at 4:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Seems like that in itself is a a lousy idea. Either the code should > respect the abstraction, or it shouldn't be declaring the variable > as a relptr in the first place. Yep. I think it should be respecting the abstraction, but the 2016 version of me failed to realize the issue when committing 13e14a78ea1. Hindsight is 20-20, perhaps. > > So we can fix this by: > > 1. Using a relative pointer value other than 0 to represent a null > > pointer. Andres suggested (Size) -1. > > 2. Not storing the free page manager for the DSM in the main shared > > memory segment at byte offset 0. > > 3. Dropping the assertion while loudly singing "la la la la la la". > > I'm definitely down on #3, because that just leaves the ambiguity > in place to bite somewhere else in future. #1 would work as long > as nobody expects memset-to-zero to produce null relptrs, but that > doesn't seem very nice either. Well, that's a good point that I hadn't considered, actually. I was thinking I'd only picked 0 as the value out of adherence to convention, but I might have had this in mind too, at the time. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: