Re: Some RELKIND macro refactoring

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Some RELKIND macro refactoring
Дата
Msg-id 202108251331.6jfqss3vfrtv@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Some RELKIND macro refactoring  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On 2021-Aug-25, Michael Paquier wrote:

> On Tue, Aug 24, 2021 at 12:01:33PM +0200, Peter Eisentraut wrote:
> > While analyzing this again, I think I found an existing mistake.  The
> > handling of RELKIND_PARTITIONED_INDEX in RelationGetNumberOfBlocksInFork()
> > seems to be misplaced.  See attached patch.

Agreed, that's a mistake.

> Right.  This maps with RELKIND_HAS_STORAGE().  Makes me wonder whether
> is would be better to add a check on RELKIND_HAS_STORAGE() in this
> area, even if that's basically the same as the Assert() already used
> in this code path.

Well, the patch replaces the switch on individual relkind values with if
tests on RELKIND_HAS_FOO macros.  I suppose we'd have

Assert(RELKIND_HAS_STORAGE(relkind));

so the function would not even be called for partitioned indexes. (In a
quick scan of 'git grep RelationGetNumberOfBlocks' I see nothing that
would obviously call this function on a partitioned index.)

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"XML!" Exclaimed C++.  "What are you doing here? You're not a programming
language."
"Tell that to the people who use me," said XML.
https://burningbird.net/the-parable-of-the-languages/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: [PATCH] document
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump