Re: Bug with temporary child of a permanent table after recovery

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Bug with temporary child of a permanent table after recovery
Date: 2012-12-17 20:27:06
Message-ID: 1355776026.24766.39.camel@sussancws0025
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, 2012-12-16 at 21:17 -0500, Tom Lane wrote:
> I wrote:
> > On the whole I think resurrecting the rd_islocaltemp flag might be the
> > best thing. We can keep the use of "relpersistence ==
> > RELPERSISTENCE_TEMP" to do what rd_istemp used to do, it's just the
> > equation of "rd_backend == MyBackendId" with "is my temp table" that's
> > bogus. And this way gets rid of some unnecessary cross-branch coding
> > differences.
>
> Here is a draft patch for this. Thoughts/objections?

It looks good to me.

> One thing I noticed that maybe needs more work is that tablecmds.c in
> general seems mighty willing to hack upon temp tables belonging to other
> sessions. I added tests for that in the places where there already were
> checks on relpersistence, but I wonder whether we ought not simply
> forbid all forms of ALTER on nonlocal temp rels, right up at the top.

Do you see any path where an ALTER can get a hold on a non-local temp
table? Or do you just mean as a sanity check? Either way, blocking it at
the top sounds good to me.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-12-17 21:03:03 Re: Bug with temporary child of a permanent table after recovery
Previous Message Andres Freund 2012-12-17 18:20:47 Re: BUG #7756: When upgrading postgis extension get row is too big: size 9272, maximum size 8160