Re: page macros cleanup (ver 04)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: page macros cleanup (ver 04)
Дата
Msg-id 13370.1215975739@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: page macros cleanup (ver 04)  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Ответы Re: page macros cleanup (ver 04)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Список pgsql-patches
"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> ...  That macro is actually doing the
> same thing as PageGetContents, so I switched to using that. As that
> moves the data sligthly on those bitmap pages, I guess we'll need a
> catversion bump.

I'm amazed that Zdenek didn't scream bloody murder about that.  You're
creating a work item for in-place-upgrade that would not otherwise
exist, in exchange for a completely trivial bit of code beautification.
(The same can be said of his proposed change to hash meta pages.)

I'm planning to go over this patch today and apply it sans the parts
that would require catversion bump.  We can argue later about whether
those are really worth doing, but I'm leaning to "not" --- unless Zdenek
says that he has no intention of making in-place-upgrade handle hash
indexes any time soon.

BTW, after further thought about the PageGetContents() situation:
right now we can change it to guarantee maxalignment "for free",
since SizeOfPageHeaderData happens to be maxaligned on all platforms
(this wasn't the case as recently as 8.2).  So I'm thinking we should
do that.  There's at least one place that thinks that PageGetContents
is the same as page + SizeOfPageHeaderData, but that's easily fixed.
On balance it seems like hidden assumptions about alignment are a bigger
risk than assumptions about that offset --- anyone want to argue the
contrary?

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: page macros cleanup (ver 04)
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: [HACKERS] GIN improvements