Re: Bug with temporary child of a permanent table after recovery
От | Jeff Davis |
---|---|
Тема | Re: Bug with temporary child of a permanent table after recovery |
Дата | |
Msg-id | 1355776026.24766.39.camel@sussancws0025 обсуждение исходный текст |
Ответ на | Re: Bug with temporary child of a permanent table after recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug with temporary child of a permanent table after recovery
|
Список | 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
В списке pgsql-bugs по дате отправления: