From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: balazs@obiserver.hu
Cc: pgsql-bugs@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: BUG #14825: enum type: unsafe use?
Date: Sat, 23 Sep 2017 15:52:05 -0400
Message-ID: <19137.1506196325@sss.pgh.pa.us> (raw)
In-Reply-To: <928f5974-151f-0273-0221-fac213e7624f@2ndQuadrant.com>
References: <20170922185904.1448.16585@wrigleys.postgresql.org>
<15165.1506116768@sss.pgh.pa.us>
<3cece400-af56-7145-2e65-f044de1b0b68@2ndQuadrant.com>
<28968.1506136792@sss.pgh.pa.us>
<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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 09/23/2017 02:00 PM, Tom Lane wrote:
>> So I'm back to not being sure about the path forward. Maybe it would be
>> all right to say "the value added by ADD VALUE can't be used in the same
>> transaction, period". That's still a step forward compared to the pre-v10
>> prohibition on doing it at all. I don't remember if there were use-cases
>> where we really needed the exception for new-in-transaction types.
> Well, my idea was to have the test run like this:
> * is the value an old one? Test txnid of tuple. If yes it's ok
> * is the value one created by ALTER TYPE ADD VALUE? Test
> blacklist. If no, it's ok.
> * is the enum a new one? Test whitelist. If yes, it's ok.
> * anything else is not ok.
My point is that if you do 1 and 3, you don't need 2. Or if you do
2 and 3, you don't need 1. But in most cases, testing the tuple
hint bits is cheap, so you don't really want that option.
In any case, what I'm worried about is the amount of bookkeeping
overhead added by keeping a whitelist of enum-types-created-in-
current-transaction. That's less than trivial, especially since
you have to account correctly for subtransactions. And there are
common use-cases where that table will become large.
> If we just did the blacklist and stuck with our current heuristic test
> for enum being created in the current transaction, we'd still probably
> avoid 99% of the problems, including specifically the one that gave rise
> to the bug report.
True. But I'm not sure whether the heuristic test is adding anything
meaningful if we use a blacklist first. The case where it could help
is
begin;
create type t as enum();
alter type t add value 'v';
-- do something with 'v'
commit;
That perhaps is worth something, but if somebody is trying to build a new
enum type in pieces like that, doesn't it seem fairly likely that they
might throw in an ALTER OWNER or GRANT as well? My feeling is that the
lesson we need to learn is that the heuristic test isn't good enough.
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew.dunstan@2ndquadrant.com, balazs@obiserver.hu, pgsql-hackers@postgresql.org
Subject: Re: BUG #14825: enum type: unsafe use?
In-Reply-To: <19137.1506196325@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox