From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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 19:17:24 |
Message-ID: | 20100806191724.GN11611@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 06, 2010 at 03:00:35PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > 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.
>
> Perhaps run through pg_class after restart and flush anything marked
> relistemp? Although the ideal solution, probably, would be for temp
> tables to not have persistent catalog entries in the first place.
For the upcoming global temp tables, which are visible in other
sessions, how would this work?
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-08-06 19:30:57 | Re: including backend ID in relpath of temp rels - updated patch |
Previous Message | Tom Lane | 2010-08-06 19:00:35 | Re: including backend ID in relpath of temp rels - updated patch |