On Thu, Jun 9, 2016 at 8:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> 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.
>
>> Hmmm. I'll take a look.
>
> Yeah, that was pretty broken, but I believe I've fixed it.
Thanks. Looks reasonable on a quick once-over.
For the record, I think much of what constitutes "broken" is arbitrary
here - anything that doesn't work can be labelled "well, that's not
supported under parallel query, label your function
parallel-restricted or parallel-unsafe". And I think we're going to
have to take exactly that approach in many cases. I have no illusions
that the current infrastructure covers everything that users will want
to do, and I think we'll be uncovering and removing limitations of
this sort for a long time. But clearly the more state we synchronize,
the happier users will be. I probably should have done something like
what you did here sooner, but I didn't think it could be done that
simply.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company