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
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 |