Re: How about a proper TEMPORARY TABLESPACE? - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: How about a proper TEMPORARY TABLESPACE?
Date
Msg-id 53B11C7E.1080908@2ndquadrant.com
Whole thread Raw
In response to Re: How about a proper TEMPORARY TABLESPACE?  (Matheus de Oliveira <matioli.matheus@gmail.com>)
Responses Re: How about a proper TEMPORARY TABLESPACE?  (Matheus de Oliveira <matioli.matheus@gmail.com>)
List pgsql-hackers
On 06/29/2014 02:19 AM, Matheus de Oliveira wrote:
> Hi Hackers,
> 
> I have worked on that patch a little more. So now I have functional
> patch (although still WIP) attached. The feature works as following:
> 
> - Added a boolean parameter "only_temp_files" to pg_tablespace.spcoptions;
> - This parameter can be set to true only during CREATE TABLESPACE, not
> on ALTER TABLESPACE (I have thought of ways of implementing the latter,
> and I'd like to discuss it more latter);
> - On the creation of relations, it is checked if it is a
> temporary-tablespace, and an error occurs when it is and the relation is
> not temporary (temp table or index on a temp table);
> - When a temporary file (either relation file or sort/agg file) is
> created inside a temporary-tablespace, the entire directories structure
> is created on-demand (e.g. if
> pg_tblspc/<oid>/<TABLESPACE_VERSION_DIRECTORY> is missing, it is created
> on demand) it is done on OpenTemporaryFileInTablespace, at fd.c (I
> wonder if shouldn't we do that for any tablespace) and on
> TablespaceCreateDbspace, at tablespace.c.

Right now PostgreSQL appears to rely on the absence of the tablespace
directory as a flag to tell it "don't start up, something's badly wrong
here".

If the user creates the tablespace directory, it figures they at least
know what they're doing and carries on starting up with the empty
tablespace. It's treated as an admin statement - "I know it's gone, it's
not coming back, just carry on as best you can".

If Pg were to auto-create the directory, then if (say) a mount of a
tablespace dir failed at boot, Pg would still happily start up and might
create files in the tablespace, despite there being inaccessible
tables/indexes/etc on the not-mounted volume that's *supposed* to be the
tablespace storage. That'd create plenty of mess.

So no, I don't think Pg should auto-create the tablespace directory if
it's missing for non-temporary tablespaces. Not unless the current (less
than friendly) behaviour around lost tablespaces is replaced with
something like an `ignore_missing_tablespaces` or
`drop_missing_tablespaces` GUC - akin to our existing
`zero_missing_pages` recovery GUC.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Escaping from blocked send() reprised.
Next
From: Ashutosh Bapat
Date:
Subject: Re: inherit support for foreign tables