On 5/24/07, Bernd Helmle <mailings@oopsware.de> wrote:
> While looking at Jaime's last temp_tablespaces GUC patch, i've got some
> concerns about it's current implementation:
>
the original patch is from Albert Cervera =)
> 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.
>
sounds good. can we see the new patch?
> 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 reason for those messages is that the tablespace can get full or
can be dropped before use, so we throw the message for the dba to take
actions. if no one thinks is a good idea the message can be removed.
> The silent
> mechanism to drop a tablespace during temporary usage makes me a little bit
> uncomfortable about its robustness.
>
maybe using the list you put in TopMemoryContext we can deny the
ability to drop the tablespace until it's removed from the list of
temp tablespaces.
--
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