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

From Fabrízio de Royes Mello
Subject Re: How about a proper TEMPORARY TABLESPACE?
Date
Msg-id CAFcNs+ooCv2WeYi0QKRq63u0FfUoBQutX39wHNC=tu=4R0h-jA@mail.gmail.com
Whole thread Raw
In response to Re: How about a proper TEMPORARY TABLESPACE?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: How about a proper TEMPORARY TABLESPACE?  (Matheus de Oliveira <matioli.matheus@gmail.com>)
List pgsql-hackers
<div dir="ltr"><div class="gmail_extra"><br />On Wed, Jun 18, 2014 at 4:53 PM, Alvaro Herrera <<a
href="mailto:alvherre@2ndquadrant.com">alvherre@2ndquadrant.com</a>>wrote:<br />><br />> Stephen Frost
wrote:<br/>> > * Tom Lane (<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>) wrote:<br /> > > >
StephenFrost <<a href="mailto:sfrost@snowman.net">sfrost@snowman.net</a>> writes:<br />> > > > Yes.
 I'ddefinitely like to see an ALTER TABLESPACE option, with an<br />> > > > ERROR that lists out all of the
non-temporaryobjects which are found<br /> > > > > (and lists any other databases which have objects in
those<br/>> > > > tablespaces..).  That would allow administrators who have existing<br />> > >
>notionally temporary-only tablespaces to go clean things up to make them<br /> > > > > actually
temporary-only.<br/>><br />> > > I would certainly suggest that the first version of the patch not<br
/>>> > undertake to allow this property to be ALTERed; the cost-benefit<br /> > > > ratio isn't there
IMO.<br/>> ><br />> > I suppose scheduling downtime to do the check manually across all<br />> >
databases,then drop and recreate the tablespace, would work.  As<br />> > someone who's working with a couple of
thesecases, it'd be awful nice<br /> > > if there was a way PG would handle it for me.<br />><br />> I
wonderif some form of NOT VALID marking could be useful here.  Of<br />> course, this is not a constraint.  But a
mechanismof a similar spirit<br /> > seems apropos.  It seems reasonable to leave such a thing for future<br />>
improvement.<br/>><br /><br />+1<br /><br /></div><div class="gmail_extra">Then, to summarize Matheus must do:<br
/></div><divclass="gmail_extra"> * use an option instead of change the syntax and catalog to indicate that a tablespace
isused to store temp objects<br /></div><div class="gmail_extra">* throw an exception if we try ALTER the option
"only_temp_relations"<br/></div><div class="gmail_extra">* add regression tests<br /></div><div class="gmail_extra">*
adddocumentation<br /></div><div class="gmail_extra"><br />And, of course, register to the next open commitfest [1] to
getdetailed feedback and review.<br /><br />Regards,<br /><br />[1] <a
href="https://commitfest.postgresql.org/">https://commitfest.postgresql.org/</a><br/></div><div class="gmail_extra"><br
/>--<br/>Fabrízio de Royes Mello<br />Consultoria/Coaching PostgreSQL<br />>> Timbira: <a
href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/> >> Blog sobre TI: <a
href="http://fabriziomello.blogspot.com">http://fabriziomello.blogspot.com</a><br/>>> Perfil Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/> >> Twitter: <a
href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a></div></div>

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [bug fix] Memory leak in dblink
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks.