Re: Unlogged vs. In-Memory

Поиск
Список
Период
Сортировка
Искать
От
Robert Haas
Тема
Re: Unlogged vs. In-Memory
Дата
в 12:13:23
Msg-id
BANLkTimL99z0yf63f_ZgALT9UH3qxp0myA@mail.gmail.com
Ответ на
Re: Unlogged vs. In-Memory (Magnus Hagander)
Список
Дерево обсуждения
Re: Unlogged vs. In-Memory Roy Hann <specially@processed.almost.meat>
Re: Unlogged vs. In-Memory Korry Douglas <korry.douglas@enterprisedb.com>
Re: Unlogged vs. In-Memory Adrian Klaver <adrian.klaver@gmail.com>
Re: Unlogged vs. In-Memory damien clochard <damien@dalibo.info>
Re: Unlogged vs. In-Memory "Jehan-Guillaume (ioguix) de Rorthais" <ioguix@free.fr>
Re: Unlogged vs. In-Memory Rob Wultsch <wultsch@gmail.com>
Re: Unlogged vs. In-Memory "Jehan-Guillaume (ioguix) de Rorthais" <ioguix@free.fr>
Re: Unlogged vs. In-Memory Joshua Berkus <josh@agliodbs.com>
Re: Unlogged vs. In-Memory Thom Brown <thom@linux.com>
Re: Unlogged vs. In-Memory Josh Berkus <josh@agliodbs.com>
Re: Unlogged vs. In-Memory "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: Unlogged vs. In-Memory Thom Brown <thom@linux.com>
On Tue, May 3, 2011 at 2:44 PM, Magnus Hagander  wrote:
> On Tue, May 3, 2011 at 20:06, Thom Brown  wrote:
>> On 3 May 2011 19:02, Rob Wultsch  wrote:
>>> Can Unlogged tables be located on a table space mount on a ram fs
>>> without hosing the instance if the server gets bounced?
>>
>> No more than anything else in a RAM filesystem.  There are of course
>> battery-backed RAM disk devices people can use, but those are a
>> special case.
>
> I think you're missing the scenario Rob is talking about. I think he
> mentions the sequence:
>
> CREATE TABLESPACE junk LOCATION '/tmp/junk';
> CREATE UNLOGGED TABLE meh(a int) TABLESPACE junk;
> 
> rm -rf /tmp/junk/*
> 
> postgres=# select * from meh;
> ERROR:  could not open file
> "pg_tblspc/16434/PG_9.1_201104251/12008/16435": No such file or
> directory
>
> Now if the tablespace contains *only* unlogged tables, it should at
> least theoretically be possible to recover from this situation on
> startup, I think. But it's not now. Anybody have an idea about how
> much work that would be?

What you would need to do is save the _init forks of every relation
(only) and copy them back onto the ram disk before starting up
PostgreSQL.  Assuming that the set of tables is static and that you
don't perform table-rewriting operations (like CLUSTER) on them, this
wouldn't be too hard to script.

To make PG do it automatically, we'd need to store the _init forks in
a different tablespace from the remaining forks.  That's probably
possible, but it seems complicated.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-advocacy по дате отправления
От: Thomas Kellerer
Дата:
Сообщение: Re: Major features for 9.1
От: Korry Douglas
Дата:
Сообщение: Re: Unlogged vs. In-Memory
FAQ