Re: Reviewing temp_tablespaces GUC patch - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: Reviewing temp_tablespaces GUC patch
Date
Msg-id 9C417F7EECA3487AD4E581C3@imhotep.credativ.de
Whole thread Raw
In response to Re: Reviewing temp_tablespaces GUC patch  ("Jaime Casanova" <systemguards@gmail.com>)
Responses Re: Reviewing temp_tablespaces GUC patch
Re: Reviewing temp_tablespaces GUC patch
List pgsql-hackers
--On Freitag, Mai 25, 2007 00:02:06 +0000 Jaime Casanova
<systemguards@gmail.com> wrote:


> the original patch is from Albert Cervera =)

Ah, missed that, thanks ;)


>>
>
> sounds good. can we see the new patch?

Attached tablespace.c.diff shows my current changes to use an OID  lookup
list.

>
> 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.
>

I could imagine that this could irritate DBA's (at least, that is what
happened to me during testing). It's okay that someone could drop a
tablespace concurrently to other transactions, but i have concerns that
with temp_tablespaces this could happen during _queries_. Do queries
delete/recreate temp files during execution, maybe within sorts so that the
used temp tablespace looks empty for a certain period of time?

>> 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.

That would mean we have to share this information between backends. This
looks complicated since every user could have its own temp_tablespaces
GUC....


--
  Thanks

                    Bernd
Attachment

pgsql-hackers by date:

Previous
From: Bernd Helmle
Date:
Subject: Re: Reviewing temp_tablespaces GUC patch
Next
From: Tom Lane
Date:
Subject: Re: Reviewing temp_tablespaces GUC patch