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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster