Re: Some other things about contrib/bloom and generic_xlog.c

> mainline XLOG replay.  Shouldn't generic_xlog.c take the same trouble?
Yes, it should. Alexander now works on it.

>
> 2. Unless I'm missing something, contrib/bloom is making no effort
> to ensure that bloom index pages can be distinguished from other pages
> by pg_filedump.  That's fine if your expectation is that bloom will always
> be a toy with no use in production; but otherwise, not so much.  You need
> to make sure that the last two bytes of the page special space contain a
> uniquely identifiable code; compare spgist_page_id in SPGiST indexes.

Now contrib/bloom is a canonical example how to implement yourown index and how 
to use generic WAL interface. And it is an useful toy: in some cases it could 
help in production system, patch attached. I'm a little dissatisfied with patch 
because I had to add unused field to BloomPageOpaqueData, in opposite case size 
of BloomPageOpaqueData struct equals 6 bytes but special size is MAXALIGNED, so, 
last two bytes will be unused. If unused field is not a problem, I will push 
this patch.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/