Re: Adjusting index special storage for pg_filedump's convenience

On Mon, 9 Apr 2007, Tom Lane wrote:

> 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.

Sounds... reasonable. Especially if you add the flags test below.

>
> 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?)

Yes, I've reduced this already but hadn't in previous patches, from
memory. I'd add a filler of uint16 now. Got a number I should use?

> 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.

Sounds like the only workable approach.

Thanks,

Gavin