unlogged tables v5

Here's an updated patch for unlogged tables, incorporating the
following changes since v4:

1. pg_dump and pg_dumpall now take an argument
--no-unlogged-table-data, which does just about what it sounds like.
In a previous email, I suggested that what we wanted here was
--no-unlogged-tables, but on further thought I don't think that's
right. There's no reason to think that the schema of an unlogged
table shouldn't be backed up, just the contents.

2. Documentation improvements, including changes to catalogs.sgml and
storage.sgml, per observations from Tom Lane.

3. Unlogged buffers are no longer included in a non-shutdown
checkpoint, which should improve performance for some workloads. This
is implemented via a new flag BM_PERMANENT, which made the logic a bit
simpler than BM_UNLOGGED with the opposite sense would have done. It
could be argued that this flag out to be called
BM_SKIP_CHECKPOINTS_EXCEPT_SHUTDOWN_CHECKPOINTS, or something like
that, but I think that's gilding the lily.

4. Unlogged tables now survive a clean shutdown. (Note that this is
not incompatible with #3: IF a buffer is written, the relation file
will be fsync'd; #3 just affects how often they get written in the
first place.)

5. Support unlogged GIN indexes.

There are a couple of open issues which I'm thinking can be left for
future work.

A. Minimization of fsync traffic. fsyncs on unlogged relations can
potentially be postponed until shutdown time. Right now, they'll
happen as part of the next checkpoint.

B. Unlogged GIST indexes aren't supported. Making this work appears
to require (i) requiring every page in shared buffers to have not only
an LSN but a full page header, (ii) allocating a flag bit in the page
header to designate that the LSN isn't real and no XLogFlush should be
done, (iii) creating a shared-memory counter that will generate fake
LSNs for use by the GIST index code and adjusting the GIST code to use
this (and set the bit described in (ii)) when an unlogged GIST is in
memory, (iv) storing the counter described in (iii) somewhere (perhaps
in the control file) on shutdown so that after a clean shutdown and
restart the value continues to increase monotonically. I'm not
entirely convinced that the penny is worth the candle here.

I'm thinking this is about ready to commit. Further review and
testing would be appreciated, especially of these latest changes.

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