On 2017-10-03 19:53:41 -0400, Andrew Dunstan wrote: > On 09/27/2017 02:52 PM, Tom Lane wrote: > > Andrew Dunstan <andrew.duns...@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-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers