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: | Raw Message | Whole Thread | 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 |