Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use? - Mailing list pgsql-bugs

From Tom Lane
Subject Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?
Date
Msg-id 12792.1506456422@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] BUG #14825: enum type: unsafe use?  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?
List pgsql-bugs
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 09/26/2017 02:37 PM, Tom Lane wrote:
>> ... 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.

> 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.

Meh.  I'm starting to slide back to my original opinion that we should
revert back to 9.6 behavior.  Even if a post-RC1 catversion bump is OK,
making these sorts of changes a week before GA is not comfort inducing.
I'm losing faith that we've thought through the issue thoroughly, and
there's no longer time to catch any remaining oversights through testing.

Any other votes out there?
        regards, tom lane


-- 
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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #14827: "ALTER TABLE... IF NOT EXISTS...ADD.. BIGSERIAL" leaves extra sequences
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: [BUGS] BUG #14827: "ALTER TABLE... IF NOT EXISTS...ADD..BIGSERIAL" leaves extra sequences