Reviewing temp_tablespaces GUC patch - Mailing list pgsql-hackers

From Bernd Helmle
Subject Reviewing temp_tablespaces GUC patch
Date
Msg-id 0EF1D9488E2104598890FAB0@imhotep.credativ.de
Whole thread Raw
Responses Re: Reviewing temp_tablespaces GUC patch  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Reviewing temp_tablespaces GUC patch  ("Jaime Casanova" <systemguards@gmail.com>)
List pgsql-hackers
While looking at Jaime's last temp_tablespaces GUC patch, i've got some
concerns about it's current implementation:

1)

The code claims that OIDs of temp tablespaces couldn't be cached, therefore 
it is parsing and
re-reading the GUCs in GetTempTablespace() with SplitIdentifierNames() over 
and over again. Because GetTempTablespace() is likely to be called many 
times in queries with a good amount of search operations, i believe this 
could be done better by allocating a list of OIDs in permanent storage 
(TopMemoryContext) and use this OID list to re-check them in 
GetTempTablespace() (i have modified the patch and it seems to work). This 
would save us to split the GUC every time.

2)

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.

Comments?

--  Thanks
                   Bernd


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Prepare/Declare
Next
From: Alvaro Herrera
Date:
Subject: Re: Reviewing temp_tablespaces GUC patch