Re: Adjusting index special storage for pg_filedump's convenience

Tom Lane wrote:
> Gavin Sherry <swm(at)alcove(dot)com(dot)au> writes:
>> On Mon, 9 Apr 2007, Tom Lane wrote:
>>> ... I don't see any way to make it completely bulletproof
>>> without enlarging the special space, which seems an unreasonable price
>>> to pay. But even one chance in 16K is way better than the current
>>> situation.
>
>> Sounds like the only workable approach.
>
> Actually, I realized after writing that that it *is* possible to make it
> bulletproof: all we have to do is make the BTCycleId wrap around at a
> little less than 64K, which adds about one line of code and doesn't
> materially change its reliability. That leaves a few bitpatterns free
> for IDs of other index types with no chance of collision. I made hash
> use 0xFF80 and gist 0xFF81; please use 0xFF82 for bitmaps. (GIN turns
> out not to need a code because its special space is a different size,
> so we can tell it apart anyway.)
>
> See patch already committed here:
> http://archives.postgresql.org/pgsql-committers/2007-04/msg00125.php

That's a clever trick, but I can't help thinking we really should have
an explicit field in the page header to indicate what kind of a page it
is. It would make life simpler for any external tools that want to peek
into pages, including migration utilities after a release or two. We've
also been talking about setting hint bits and doing some kind of retail
vacuuming in bgwriter with HOT. To do that, we need to identify heap
pages in the bgwriter. While heap pages can currently be identified by
the fact that they don't have a special area, it feels hackish, and we
might want to do something like that for index pages too in the future.

We now have a 16-bit pd_flags field in the page header. We could use a
few bits from that.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com