On 2017-10-03 19:53:41 -0400, Andrew Dunstan wrote:
> On 09/27/2017 02:52 PM, Tom Lane wrote:
> > Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> >> At this stage on reflection I agree it should be pulled :-(
> > That seems to be the consensus, so I'll go make it happen.
> >
> >> I'm not happy about the idea of marking an input function as not
> >> parallel safe, certainly not without a good deal of thought and
> >> discussion that we don't have time for this cycle.
> > I think the way forward is to do what we had as of HEAD (984c92074),
> > but add the ability to transmit the blacklist table to parallel
> > workers. Since we expect the blacklist table would be empty most of
> > the time, this should be close to no overhead in practice. I concur
> > that the idea of marking the relevant functions parallel-restricted is
> > probably not as safe a fix as I originally thought, and it's not a
> > very desirable restriction even if it did fix the problem.
> Do you have any suggestion as to how we should transmit the blacklist to
> parallel workers?
How about storing them in the a dshash table instead of dynahash?
Similar to how we're now dealing with the shared typmod registry stuff?
It should be fairly simple to now simply add a new struct Session member
shared_enum_whatevs_table.
Greetings,
Andres Freund
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs