Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit984c920

Browse files
committed
Remove heuristic same-transaction test from check_safe_enum_use().
The blacklist mechanism added by the preceding commit directly fixesmost of the practical cases that the same-transaction test was meantto cover. What remains is use-cases likebegin;create type e as enum('x');alter type e add value 'y';-- use 'y' somehowcommit;However, because the same-transaction test is heuristic, it fails onsmall variants of that, such as renaming the type or changing itsowner. Rather than try to explain the behavior to users, let'sremove it and just have a rule that the newly added value can't beused before being committed, full stop. Perhaps later it will beworth the implementation effort and overhead to have a more accuratetest for type-was-created-in-this-transaction. We'll wait for somefield experience with v10 before deciding to do that.Back-patch to v10.Discussion:https://postgr.es/m/20170922185904.1448.16585@wrigleys.postgresql.org
1 parent1635e80 commit984c920

File tree

4 files changed

+24
-49
lines changed

4 files changed

+24
-49
lines changed

‎doc/src/sgml/ref/alter_type.sgml

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -292,8 +292,7 @@ ALTER TYPE <replaceable class="PARAMETER">name</replaceable> RENAME VALUE <repla
292292
<para>
293293
If <command>ALTER TYPE ... ADD VALUE</> (the form that adds a new value to
294294
an enum type) is executed inside a transaction block, the new value cannot
295-
be used until after the transaction has been committed, except in the case
296-
that the enum type itself was created earlier in the same transaction.
295+
be used until after the transaction has been committed.
297296
</para>
298297

299298
<para>

‎src/backend/utils/adt/enum.c

Lines changed: 9 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -48,7 +48,14 @@ static ArrayType *enum_range_internal(Oid enumtypoid, Oid lower, Oid upper);
4848
* However, it's okay to allow use of uncommitted values belonging to enum
4949
* types that were themselves created in the same transaction, because then
5050
* any such index would also be new and would go away altogether on rollback.
51-
* (This case is required by pg_upgrade.)
51+
* We don't implement that fully right now, but we do allow free use of enum
52+
* values created during CREATE TYPE AS ENUM, which are surely of the same
53+
* lifespan as the enum type. (This case is required by "pg_restore -1".)
54+
* Values added by ALTER TYPE ADD VALUE are currently restricted, but could
55+
* be allowed if the enum type could be proven to have been created earlier
56+
* in the same transaction. (Note that comparing tuple xmins would not work
57+
* for that, because the type tuple might have been updated in the current
58+
* transaction. Subtransactions also create hazards to be accounted for.)
5259
*
5360
* This function needs to be called (directly or indirectly) in any of the
5461
* functions below that could return an enum value to SQL operations.
@@ -58,7 +65,6 @@ check_safe_enum_use(HeapTuple enumval_tup)
5865
{
5966
TransactionIdxmin;
6067
Form_pg_enumen;
61-
HeapTupleenumtyp_tup;
6268

6369
/*
6470
* If the row is hinted as committed, it's surely safe. This provides a
@@ -85,40 +91,11 @@ check_safe_enum_use(HeapTuple enumval_tup)
8591
if (!EnumBlacklisted(HeapTupleGetOid(enumval_tup)))
8692
return;
8793

88-
/* It is a new enum value, so check to see if the whole enum is new */
89-
en= (Form_pg_enum)GETSTRUCT(enumval_tup);
90-
enumtyp_tup=SearchSysCache1(TYPEOID,ObjectIdGetDatum(en->enumtypid));
91-
if (!HeapTupleIsValid(enumtyp_tup))
92-
elog(ERROR,"cache lookup failed for type %u",en->enumtypid);
93-
94-
/*
95-
* We insist that the type have been created in the same (sub)transaction
96-
* as the enum value. It would be safe to allow the type's originating
97-
* xact to be a subcommitted child of the enum value's xact, but not vice
98-
* versa (since we might now be in a subxact of the type's originating
99-
* xact, which could roll back along with the enum value's subxact). The
100-
* former case seems a sufficiently weird usage pattern as to not be worth
101-
* spending code for, so we're left with a simple equality check.
102-
*
103-
* We also insist that the type's pg_type row not be HEAP_UPDATED. If it
104-
* is, we can't tell whether the row was created or only modified in the
105-
* apparent originating xact, so it might be older than that xact. (We do
106-
* not worry whether the enum value is HEAP_UPDATED; if it is, we might
107-
* think it's too new and throw an unnecessary error, but we won't allow
108-
* an unsafe case.)
109-
*/
110-
if (xmin==HeapTupleHeaderGetXmin(enumtyp_tup->t_data)&&
111-
!(enumtyp_tup->t_data->t_infomask&HEAP_UPDATED))
112-
{
113-
/* same (sub)transaction, so safe */
114-
ReleaseSysCache(enumtyp_tup);
115-
return;
116-
}
117-
11894
/*
11995
* There might well be other tests we could do here to narrow down the
12096
* unsafe conditions, but for now just raise an exception.
12197
*/
98+
en= (Form_pg_enum)GETSTRUCT(enumval_tup);
12299
ereport(ERROR,
123100
(errcode(ERRCODE_UNSAFE_NEW_ENUM_VALUE_USAGE),
124101
errmsg("unsafe use of new value \"%s\" of enum type %s",

‎src/test/regress/expected/enum.out

Lines changed: 8 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -656,18 +656,16 @@ select enum_range(null::bogon);
656656
(1 row)
657657

658658
ROLLBACK;
659-
--check that we can add new values to existing enums in a transaction
660-
--and use them, ifthetype is new as well
659+
--ideally, we'd allow this usage; but it requires keeping track of whether
660+
--the enum type was created inthecurrent transaction, which is expensive
661661
BEGIN;
662662
CREATE TYPE bogus AS ENUM('good');
663-
ALTER TYPE bogus ADD VALUE 'bad';
664-
ALTER TYPE bogus ADD VALUE 'ugly';
665-
SELECT enum_range(null::bogus);
666-
enum_range
667-
-----------------
668-
{good,bad,ugly}
669-
(1 row)
670-
663+
ALTER TYPE bogus RENAME TO bogon;
664+
ALTER TYPE bogon ADD VALUE 'bad';
665+
ALTER TYPE bogon ADD VALUE 'ugly';
666+
select enum_range(null::bogon); -- fails
667+
ERROR: unsafe use of new value "bad" of enum type bogon
668+
HINT: New enum values must be committed before they can be used.
671669
ROLLBACK;
672670
--
673671
-- Cleanup

‎src/test/regress/sql/enum.sql

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -315,13 +315,14 @@ ALTER TYPE bogus RENAME TO bogon;
315315
select enum_range(null::bogon);
316316
ROLLBACK;
317317

318-
--check that we can add new values to existing enums in a transaction
319-
--and use them, ifthetype is new as well
318+
--ideally, we'd allow this usage; but it requires keeping track of whether
319+
--the enum type was created inthecurrent transaction, which is expensive
320320
BEGIN;
321321
CREATETYPEbogusAS ENUM('good');
322-
ALTERTYPE bogus ADD VALUE'bad';
323-
ALTERTYPE bogus ADD VALUE'ugly';
324-
SELECT enum_range(null::bogus);
322+
ALTERTYPE bogus RENAME TO bogon;
323+
ALTERTYPE bogon ADD VALUE'bad';
324+
ALTERTYPE bogon ADD VALUE'ugly';
325+
select enum_range(null::bogon);-- fails
325326
ROLLBACK;
326327

327328
--

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp