Reviewing temp_tablespaces GUC patch

Поиск
Список
Период
Сортировка
От Bernd Helmle
Тема Reviewing temp_tablespaces GUC patch
Дата
Msg-id 0EF1D9488E2104598890FAB0@imhotep.credativ.de
обсуждение исходный текст
Ответы Re: Reviewing temp_tablespaces GUC patch  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Reviewing temp_tablespaces GUC patch  ("Jaime Casanova" <systemguards@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Prepare/Declare
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Reviewing temp_tablespaces GUC patch