From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Subject: Re: BUG #14825: enum type: unsafe use?
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David E. Wheeler" <david@justatheory.com>,
 Christophe Pettus <christophe.pettus@pgexperts.com>,
 pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org
References: <20170922185904.1448.16585@wrigleys.postgresql.org>
 <f29e2d7e-7d71-b3b7-2fed-d52bddd8ca61@2ndQuadrant.com>
 <24380.1506179805@sss.pgh.pa.us> <16272.1506189656@sss.pgh.pa.us>
 <928f5974-151f-0273-0221-fac213e7624f@2ndQuadrant.com>
 <19137.1506196325@sss.pgh.pa.us>
 <4942e2c0-3302-f496-d4c1-a967f77d0143@2ndQuadrant.com>
 <25662.1506204381@sss.pgh.pa.us>
 <9479302a-09b8-4264-f9c4-514b65f18547@2ndQuadrant.com>
 <18127.1506285450@sss.pgh.pa.us>
 <2770f70a-5977-3fa1-1065-11b4cc69f07f@2ndQuadrant.com>
 <23438.1506294409@sss.pgh.pa.us>
 <a9a175c3-164b-6997-8b97-c04d1c2df753@2ndQuadrant.com>
 <25809.1506348877@sss.pgh.pa.us>
 <b2890b9d-2383-955f-786c-8e252dce04cb@2ndQuadrant.com>
 <27064.1506350579@sss.pgh.pa.us>
 <5f4f29bf-90b1-e49a-6cf9-069c59bc1067@2ndQuadrant.com>
 <40FDB1F3-932D-4912-B4C7-F1E26E331079@justatheory.com>
 <7ca5214d-f981-54e4-c65a-470a87aa665e@2ndQuad! ! ! rant.com>
 <1090.1506365074@sss.pgh.pa.us> <9666.1506446327@sss.pgh.pa.us>
 <329.1506451066@sss.pgh.pa.us>
Message-ID: <38835cdd-c378-8d7a-013b-fd733c78c649@2ndQuadrant.com>
Date: Tue, 26 Sep 2017 15:33:03 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <329.1506451066@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-MW
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org


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