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

From Alvaro Herrera
Subject Re: How about a proper TEMPORARY TABLESPACE?
Date
Msg-id 20140618195333.GM18688@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: How about a proper TEMPORARY TABLESPACE?  (Stephen Frost <sfrost@snowman.net>)
Responses Re: How about a proper TEMPORARY TABLESPACE?  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
List pgsql-hackers
Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > Stephen Frost <sfrost@snowman.net> writes:
> > > Yes.  I'd definitely like to see an ALTER TABLESPACE option, with an
> > > ERROR that lists out all of the non-temporary objects which are found
> > > (and lists any other databases which have objects in those
> > > tablespaces..).  That would allow administrators who have existing
> > > notionally temporary-only tablespaces to go clean things up to make them
> > > actually temporary-only.

> > I would certainly suggest that the first version of the patch not
> > undertake to allow this property to be ALTERed; the cost-benefit
> > ratio isn't there IMO.
> 
> I suppose scheduling downtime to do the check manually across all
> databases, then drop and recreate the tablespace, would work.  As
> someone who's working with a couple of these cases, it'd be awful nice
> if there was a way PG would handle it for me.

I wonder if some form of NOT VALID marking could be useful here.  Of
course, this is not a constraint.  But a mechanism of a similar spirit
seems apropos.  It seems reasonable to leave such a thing for future
improvement.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks.
Next
From: Josh Berkus
Date:
Subject: Re: idle_in_transaction_timeout