Tom Lane wrote:
Gavin Sherry <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
