Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use? |
Дата | |
Msg-id | 20171004013856.2xzd2nw6oufbbtms@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use? (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: