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