Skip site navigation (1) Skip section navigation (2)

Re: Adjusting index special storage for pg_filedump's convenience

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gavin Sherry <swm(at)alcove(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adjusting index special storage for pg_filedump's convenience
Date: 2007-04-16 08:42:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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:

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

In response to


pgsql-hackers by date

Next:From: Jacky LengDate: 2007-04-16 09:15:22
Subject: Why xlog stuff is done after the filetruncate op in smgrtruncate?
Previous:From: Martin LanghoffDate: 2007-04-16 07:18:23
Subject: Hacking on PostgreSQL via GIT

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group