Re: Unlogged vs. In-Memory
От
Robert Haas
Тема
Re: Unlogged vs. In-Memory
Дата
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 по дате отправления