On 13/09/10 05:49, Robert Haas wrote:
On Mon, Sep 6, 2010 at 10:55 PM, Robert Haas<robertmh...@gmail.com> wrote:
3. With respect to unlogged tables, the major obstacle seems to be
figuring out a way for these to get automatically truncated at startup
time. As with temporary table cleanup in general, the problem here is
that you can't do the obvious thing of iterating through pg_class and
truncating each unlogged table you find without greatly complicating
the startup sequence. However, I think there's a fairly easy way
around this problem: truncating a table basically means removing all
segments and relation forks other than the first segment of the main
fork, and truncating that one to zero length. So we could do it the
same way we clean up temporary files - namely, based on the file name
- if we made the filenames for unlogged tables distinguishable from
those for regular and temporary tables. What I'm thinking about is
reserving a backend ID of -2 for this purpose via some suitable
constant definition, just as -1 (InvalidBackendId) represents a
permanent table in this context.
I tried this approach and got fairly far with it, but ran into a snag
in the buffer manager. It's fairly obvious that the buffer manager
has to know whether a particular buffer is from an unlogged relation
or not; for example, FlushBuffer() should skip the XLOG flush for an
unlogged buffer, and must pass the correct backend ID to smgropen().
So my first thought was just to define a bit BM_IS_UNLOGGED, with the
obvious interpretation.
The LSNs on all pages in an unlogged relation should be zero, and
XLogFlush() will do nothing. That's what we rely on at the moment for
pages that are not WAL-logged for some reason, I don't think you need
any extra flag for that.
So I went looking for bit-space in the buffer tag and quickly found
some. ForkNumber is an enum which I suppose means a 32-bit integer,
but we've only got three forks right now and it's hard to imagine more
than a handful of additional ones, so what I'm tempted to do is change
this from an enum to a 2-byte integer and replace the enum values with
#defines. That frees up 2 bytes in the buffer tag which is more than
plenty.
I haven't been following the discussion so I don't understand why you
need the extra bits, but no objections to reducing the fork number field.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
