Re: Reviewing temp_tablespaces GUC patch

From: "Jaime Casanova" <systemguards(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Bernd Helmle" <mailings(at)oopsware(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reviewing temp_tablespaces GUC patch
Date: 2007-05-25 00:04:01
Message-ID: c2d9e70e0705241704m1d1e01abs6bb1b07a30926b36@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/24/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Bernd Helmle escribió:
>
> > It's possible that someone could drop a temporary tablespace between
> > subsequent usage of GetTempTablespace() when they are empty. This leads to
> > strange NOTICEs like
> >
> > NOTICE: could not create temporary file
> > "pg_tblspc/16387/pgsql_tmp/pgsql_tmp19942.0"
> >
> > during query execution. However, the code is save enough and switches back
> > to base/pgsql_tmp then, but this looks a little bit ugly to me. The silent
> > mechanism to drop a tablespace during temporary usage makes me a little bit
> > uncomfortable about its robustness.
>
> What happens if you create a cursor that stores something (sort
> intermediate results?) in a temp tablespace, FETCH some from it, then
> someone else drops the tablespace and FETCH some more?
>

you can't drop a tablespace that is not empty.

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-05-25 01:11:38 Re: Reviewing temp_tablespaces GUC patch
Previous Message Jaime Casanova 2007-05-25 00:02:06 Re: Reviewing temp_tablespaces GUC patch