Re: blending fast and temp space volumes

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Rick Otten <rottenwindfish@gmail.com>, "pgsql-performa." <pgsql-performance@postgresql.org>
Date: 2018-02-21T20:09:04Z
Lists: pgsql-performance
On Wed, Feb 21, 2018 at 12:07 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Wed, Feb 21, 2018 at 4:50 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>> On Wed, Feb 21, 2018 at 7:53 AM, Rick Otten <rottenwindfish@gmail.com> wrote:
>>> side note:  The disadvantage of local SSD is that it won't survive "hitting
>>> the virtual power button" on an instance, nor can it migrate automatically
>>> to other hardware.  (We have to hit the power button to add memory/cpu to
>>> the system, and sometimes the power button might get hit by accident.)  This
>>> is OK for temp space.  I never have my database come up automatically on
>>> boot, and I have scripted the entire setup of the temp space volume and data
>>> structures.  I can run that script before starting the database.   I've done
>>> some tests and it seems to work great.  I don't mind rolling back any
>>> transaction that might be in play during a power failure.
>>
>> It sounds like you're treating a temp_tablespaces tablespace as
>> ephemeral, which IIRC can have problems that an ephemeral
>> stats_temp_directory does not have.
>
> For instance?
>
> I've been doing that for years without issue. If you're careful to
> restore the skeleton directory structure at server boot up, I haven't
> had any issues.

Then you clearly know what I mean already. That's not documented as
either required or safe anywhere.

-- 
Peter Geoghegan