1-byte id for SharedInvalidationMessages

On Fri, Aug 6, 2010 at 2:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Do you think it's worth worrying about the reduction in the number of
>> possible SI message types?
>
> IIRC the number of message types is the number of catalog caches plus
> half a dozen or so.  We're a long way from exhausting even a 1-byte
> ID field; and we could play more games if we had to, since there would
> be a padding byte free in the message types that refer to a catalog
> cache.  IOW, 1-byte id doesn't bother me.

I took a look at what is required to implement $SUBJECT tonight and it
appears to be remarkably straightforward.  I suppose this qualifies as
a reason to increment WAL_PAGE_MAGIC, since SharedInvalidationMessages
are now xlogged; and I added an Assert() to
AddCatCacheInvalidationMessage to detect overruns of the id field, but
other than that it seems to be just a matter of s/int16/int8/ in a
handful of places.

For those following along at home:

http://archives.postgresql.org/pgsql-hackers/2010-07/msg00355.php [the
patch for which this is a prerequisite]
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00366.php [why
it needs it]
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00425.php [how
this helps]

Thoughts?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company