Re: [BUGS] BUG #14825: enum type: unsafe use?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: "David E. Wheeler" <david@justatheory.com>, Christophe Pettus <christophe.pettus@pgexperts.com>, pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org
Date: 2017-09-26T20:07:02Z
Lists: pgsql-bugs, pgsql-hackers
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


Commits

  1. Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.

  2. Remove heuristic same-transaction test from check_safe_enum_use().

  3. Use a blacklist to distinguish original from add-on enum values.

  4. Add support for coordinating record typmods among parallel workers.