Re: MaxOffsetNumber for Table AMs
От | Jeff Davis |
---|---|
Тема | Re: MaxOffsetNumber for Table AMs |
Дата | |
Msg-id | 5956978897311977af631564d122af1dbd70fe15.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: MaxOffsetNumber for Table AMs (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Tue, 2021-05-04 at 12:56 -0400, Robert Haas wrote: > b. If you actually meant "less than or equal to MaxOffsetNumber", > > that will fail with the GIN posting list issue raised in my first > > email. Do you agree that's a bug? > > Given the above, yes. If we just subtracted one, it would fit in 11 bits, and that would be fine because zero is invalid anyway. Unfortunately, it's on disk, so I think we are stuck with it. Regardless, the other limitation in tidbitmap.c is more strict anyway (MaxHeapTuplesPerPage=291). > > Because of stuff like this: > > [rhaas EDBAS]$ git grep -F '[MaxOffsetNumber' > src/backend/access/gist/gistvacuum.c: OffsetNumber > todelete[MaxOffsetNumber]; > src/backend/access/gist/gistvacuum.c: OffsetNumber > todelete[MaxOffsetNumber]; > src/backend/access/gist/gistvacuum.c: BlockNumber > leafs_to_delete[MaxOffsetNumber]; > src/backend/access/hash/hash.c: OffsetNumber > deletable[MaxOffsetNumber]; > src/backend/access/hash/hashinsert.c: OffsetNumber > deletable[MaxOffsetNumber]; > src/backend/access/hash/hashovfl.c: OffsetNumber > deletable[MaxOffsetNumber]; I don't think those are problems because they represent items on an *index* page, not ItemPointers coming from a table. Regards, Jeff Davis
В списке pgsql-hackers по дате отправления: