On Sat, Nov 13, 2010 at 7:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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"?
We've been over this ground before. You can't read from non-shared catalogs without binding to a database, and you must reinitialize all unlogged relations before opening the database for a connection. So what you're proposing would involving launching a worker process for each database in the cluster, having it do its thing and then exit, and only after all that's done opening the database for connections. That seems vastly more complex and less performant than what I've done here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
