Re: page macros cleanup (ver 04) - Mailing list pgsql-patches

From Tom Lane
Subject Re: page macros cleanup (ver 04)
Date
Msg-id 13370.1215975739@sss.pgh.pa.us
Whole thread Raw
In response to Re: page macros cleanup (ver 04)  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: page macros cleanup (ver 04)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: page macros cleanup (ver 04)
Next
From: Teodor Sigaev
Date:
Subject: Re: [HACKERS] GIN improvements