Re: [BUGS] BUG #14825: enum type: unsafe use?
От | Andrew Dunstan |
---|---|
Тема | Re: [BUGS] BUG #14825: enum type: unsafe use? |
Дата | |
Msg-id | 38835cdd-c378-8d7a-013b-fd733c78c649@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14825: enum type: unsafe use? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?
|
Список | pgsql-bugs |
On 09/26/2017 02:37 PM, Tom Lane wrote: > I wrote: >> Pushed; sorry for the delay. > ... and the buildfarm's not too happy. It looks like force_parallel_mode > breaks all the regression test cases around unsafe enums; which on > reflection is unsurprising, because parallel workers will not have access > to the parent's blacklist hash, so they will think unsafe values are safe. > > Now, as long as parallel workers are read-only, perhaps this matters > little; they would not be allowed to write unsafe values into tables > anyway. I'm concerned though about whether it might be possible for a > parallel worker to return an unsafe value to the parent (in OID form) > and then the parent writes it into a table. If we can convince ourselves > that's not possible, it might be okay to just turn off force_parallel_mode > for these test cases. > > A safer answer would be to mark enum_in() and other callers of > check_safe_enum_use() as parallel-restricted. That'd require a > post-RC1 catversion bump, which seems pretty unpleasant, but > none of the other answers are nice either. > > Transmitting the blacklist hash to workers would be a good long-term > answer, but I don't want to try to shoehorn it in for v10. > > Another idea is that maybe the existence of a blacklist hash should > be enough to turn off parallel mode altogether ... but ugh. > > Or maybe we're back to "revert the whole feature, go back to 9.6 > behavior". > > Thoughts? I think I would mark enum_in and friends as parallel-restricted. Yes I know it would involve a cat version bump, so I'll understand if that's not acceptable, but it seems to me the best of a bad bunch of choices. Second choice might be turning off parallel mode if the hash exists, but I'm unclear how that would work. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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 по дате отправления: