Re: unlogged tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: unlogged tables
Date
Msg-id 26911.1289697315@sss.pgh.pa.us
Whole thread Raw
In response to Re: unlogged tables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: unlogged tables
Re: unlogged tables
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Nov 13, 2010 at 7:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

The fact that it's easy doesn't make it workable.  I would point out for
starters that AMs might (do) put WAL locations and/or XIDs into indexes.
Occasionally copying very old LSNs or XIDs back into active files seems
pretty dangerous.

Cleanup at first connection is something we've been avoiding for years,
but maybe it's time to bite the bullet and do that?

BTW, how will all of this activity look to a hot-standby slave?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: unlogged tables
Next
From: Bruce Momjian
Date:
Subject: Re: duplicate connection failure messages