Re: unlogged tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: unlogged tables
Дата
Msg-id 26911.1289697315@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: unlogged tables  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: unlogged tables  (Robert Haas <robertmhaas@gmail.com>)
Re: unlogged tables  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: unlogged tables
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: duplicate connection failure messages