Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akAGQ-0000Ep-At for pgsql-hackers@arkaria.postgresql.org; Sun, 27 Mar 2016 12:57:54 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1akAGP-0003LZ-Ey for pgsql-hackers@arkaria.postgresql.org; Sun, 27 Mar 2016 12:57:53 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1akAGN-0003LQ-G5 for pgsql-hackers@postgresql.org; Sun, 27 Mar 2016 12:57:51 +0000 Received: from relay6-d.mail.gandi.net ([2001:4b98:c:538::198]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1akAGF-0001eX-Uw for pgsql-hackers@postgresql.org; Sun, 27 Mar 2016 12:57:49 +0000 Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 7F361FB89F; Sun, 27 Mar 2016 14:57:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id dSLOdbw1knDn; Sun, 27 Mar 2016 14:57:39 +0200 (CEST) X-Originating-IP: 98.122.164.227 Received: from [192.168.10.146] (unknown [98.122.164.227]) (Authenticated sender: adsend@dunslane.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 5DB22FB883; Sun, 27 Mar 2016 14:57:37 +0200 (CEST) Subject: Re: Alter or rename enum value To: Christophe Pettus References: <56E049CC.8010201@dunslane.net> <25605.1457539654@sss.pgh.pa.us> <56E05635.70908@dunslane.net> <28167.1457543612@sss.pgh.pa.us> <56F49CF8.8050007@BlueTreble.com> <27476.1458876456@sss.pgh.pa.us> <56F58876.6020508@dunslane.net> <56F6827F.9040104@dunslane.net> <3202.1459002341@sss.pgh.pa.us> <56F69F5C.1060408@dunslane.net> Cc: Tom Lane , "David G. Johnston" , Matthias Kurz , Jim Nasby , "pgsql-hackers@postgresql.org" From: Andrew Dunstan Message-ID: <56F7D8BF.5000000@dunslane.net> Date: Sun, 27 Mar 2016 08:57:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 03/27/2016 12:43 AM, Christophe Pettus wrote: > On Mar 26, 2016, at 7:40 AM, Andrew Dunstan wrote: >> It would be nice if we could find a less broad brush approach to dealing with the issue. > I don't know how doable this is, but could we use the existing mechanism of marking an index invalid if it contains an enum type to which a value was added, and the transaction was rolled back? For the 90% use case, that would be acceptable, I would expect. > The more I think about this the more I bump up against the fact that almost anything we do might want to do to ameliorate the situation is going to be rolled back. The only approach I can think of that doesn't suffer from this is to abort if an insert/update will affect an index on a modified enum. i.e. we prevent the possible corruption from happening in the first place, as we do now, but in a much more fine grained way. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers