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

Andrew Dunstan <andrew.dunstan@2ndquadrant.com>

From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Bruce Momjian <bruce@momjian.us>, "David E. Wheeler" <david@justatheory.com>, Christophe Pettus <christophe.pettus@pgexperts.com>, pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org
Date: 2017-10-03T23:53:41Z
Lists: pgsql-bugs, pgsql-hackers

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?

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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.