Re: unlogged tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: unlogged tables
Date
Msg-id 26250.1289695319@sss.pgh.pa.us
Whole thread Raw
In response to unlogged tables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: unlogged tables
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 2. The second one (unlogged-tables-v1) adds support for unlogged
> tables by adding a new supported value for relpersistence. I made this
> work by having backend that creates an unlogged relation write out an
> "init" fork for that relation.  The main fork is nuked and replaced by
> the contents of the init fork during startup.  But I haven't made this
> code work yet for index types other than btree, so attempting to
> define a non-btree index on an unlogged relation will currently result
> in an error.  I don't think that's probably too hard to fix, but I
> haven't done it yet.

That seems pretty gross.  If you're going to have to take a special
action at startup anyway, why wouldn't it take the form of "truncate,
then if it's an index, call the appropriate ambuild function"?  Maybe
that's a bit ugly, but at least the ugliness is localized rather than
scribbled all over the filesystem.  I'm also concerned about possible
failure modes having to do with the "init fork" being missing or
corrupted.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: unlogged tables
Next
From: A.M.
Date:
Subject: POSIX shared memory redux