Adjusting index special storage for pg_filedump's convenience

Historically, pg_filedump
http://sources.redhat.com/rhdb/utilities.html
has relied on the size of a page's special space to determine which kind
of index it is looking at (btree, hash, etc) so that it can dump the
contents of the special space nicely. This is pretty ugly of course,
but there isn't a whole lot of other context available. (Before you
say "why not look at the metapage?", consider that we may be looking at
a segment file that doesn't contain the metapage, and gist and gin don't
use one anyway.) As of 8.2 it's entirely broken for gist because gist
and btree now have the same-size special space, ie 16 bytes; and it
looks like bitmap indexes will too.

We put in a workaround a long time ago to make it possible to tell the
difference between btree and hash special space, which are also the same
size: there's an unused 16 bits in hash special space that we fill with
a specific value. As of 8.2 this doesn't work as well as it used to,
because the corresponding space in a btree page is now used for a vacuum
cycle ID and so there's 1 chance in 65536 of a false match. Still, it's
a lot better than nothing.

I'd like to tweak things for 8.3 so that pg_filedump can work reasonably
well again. It looks like the hash solution would work for gist, gin,
and bitmap: rearranging fields would allow us to put in a 16-bit ID
field in all three cases. (For bitmap, I'm assuming that
bm_hrl_words_used could be reduced to 16 bits without problem --- it is
a per-page count not something larger, right?)

One problem with that is that with four special values, there'd be 1
chance in 16384 of misidentifying a btree page because of chance values
of the vacuum cycle ID. This can be improved a bit if we put the flags
fields (for those index types that have 'em) in a consistent place too:
we can disbelieve that an index is of type X if it doesn't have a flags
value that fits. 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.

Thoughts, objections, better ideas?

regards, tom lane