On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> It seems like the only reason that we would need such a flag is that
>>> applying has_parallel_hazard() to a Var is a bit expensive thanks to
>>> the typeid_is_temp() test --- but if you ask me, that test is stupid
>>> and should be removed. What's the argument for supposing that a temp
>>> table's rowtype is any more mutable intra-query than any other rowtype?
>
>> That error is coming from relation_open(). It might be possible to
>> find a way to nerf the check in relation_open() enough to let this
>> case work while making the cases that we need to fail still fail,
>
> Well, yeah, you could remove it. It's inappropriate. The right place
> for such an error check is an attempt to actually access any data within
> a temp table, ie someplace in localbuf.c. There is no reason a worker
> shouldn't be allowed to look at the catalog entries for a temp table;
> they're just like any other catalog entries.
That's a possibility. Do you think it's a good idea to go making such
changes right now, with beta2 just around the corner? Do you want to
work on it? Are you asking me to work on it?
There's one other related thing I'm concerned about, which is that the
code in namespace.c that manages pg_temp doesn't know anything about
parallelism. So it will interpret pg_temp to mean the pg_temp_NNN
schema for its own backend ID rather than the leader's backend ID.
I'm not sure that's a problem, but I haven't thought deeply about it.
Could you answer my question about whether adjust_appendrel_attrs()
might translate Vars into non-Vars? The code comment in that function
header doesn't seem to me to very clear about it. I'm guessing that
the answer is yes, so maybe the line of code you're complaining about
should just say:
childrel->reltarget_has_non_vars = true;
...but that seems like it might suck.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company