Re: including backend ID in relpath of temp rels - updated patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: including backend ID in relpath of temp rels - updated patch
Date: 2010-08-06 18:36:18
Message-ID: AANLkTi=7Tx1e5HqG_Ozq-7-dst9VwD1i2YvhQ6w8pdCe@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 6, 2010 at 2:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jaime Casanova <jaime(at)2ndquadrant(dot)com> writes:
>> On Fri, Aug 6, 2010 at 12:50 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> Just "DROP TABLE pg_temp_2.foo" or whatever and away you go.
>
>> wow! that's true... and certainly a bug...
>
> No, it's not a bug.  You'll find only superusers can do it.
>
>> we shouldn't allow any session to drop other session's temp tables, or
>> is there a reason for this misbehavior?
>
> It is intentional, though I'd be willing to give it up if we had more
> bulletproof crash-cleanup of temp tables --- which is one of the things
> this patch is supposed to result in.

This patch only directly addresses the issue of cleaning up the
storage, so there are still the catalog entries to worry about. But
it doesn't seem impossible to think about building on this approach to
eventually handle that part of the problem better, too. I haven't
thought too much about what that would look like, but I think it could
be done.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-06 18:43:10 Re: including backend ID in relpath of temp rels - updated patch
Previous Message Tom Lane 2010-08-06 18:32:33 Re: Initial review of xslt with no limits patch