Re: Temporary tablespaces on a RAM disk

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron <ronljohnsonjr(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Temporary tablespaces on a RAM disk
Date: 2020-03-17 19:22:07
Message-ID: 18467.1584472927@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ron <ronljohnsonjr(at)gmail(dot)com> writes:
> On 3/17/20 12:19 PM, David G. Johnston wrote:
>> There is a nice big bold warning callout in the documentation that covers
>> this explicitly.
>> https://www.postgresql.org/docs/12/manage-ag-tablespaces.html

>>> Warning
>>> Placing a tablespace on a temporary file system like a RAM disk risks the
>>> reliability of the entire cluster.

> But aren't temporary files removed when you restart Postgres?  (I'm assuming
> that temp_tablespaces is treated "the same" as data/pgsql_tmp.  Is that a
> false assumption?)

I think the main issue is that there's no mechanism preventing you from
putting regular (non-temp) tables into the "temporary" tablespace.
If you do, crash recovery will get very unhappy when it tries to replay
updates for those tables and they're not there.

There are probably additional issues having to do with the tablespace
directory(s) disappearing. That, you could maybe finesse by having the
postmaster start script re-create any missing directories.

All in all, I wouldn't try it without careful pre-testing of what happens
after the RAM disk gets wiped.

People have asked about this before, so maybe it'd be an idea to make
an explicit concept of a temp tablespace that only accepts temp tables,
and do whatever is needful to make that robust. But I've not heard of
any work towards that.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Daniel Westermann (DWE) 2020-03-17 19:26:36 Re: Temporary tablespaces on a RAM disk
Previous Message Ron 2020-03-17 17:59:57 Re: Temporary tablespaces on a RAM disk