| From: | Bernd Helmle <mailings(at)oopsware(dot)de> | 
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org | 
| Cc: | systemguards(at)gmail(dot)com | 
| Subject: | Reviewing temp_tablespaces GUC patch | 
| Date: | 2007-05-24 22:32:01 | 
| Message-ID: | 0EF1D9488E2104598890FAB0@imhotep.credativ.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-05-24 23:18:44 | Re: Reviewing temp_tablespaces GUC patch | 
| Previous Message | Andrew Dunstan | 2007-05-24 21:00:00 | Re: Concurrent psql patch |