aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/typecmds.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-09-27 16:14:37 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-09-27 16:14:37 -0400
commit93a1af0b3f63838774a9e524589344c3d44c867d (patch)
treee12c9d5a1331dd100a8a15b72962732e41dd03a6 /src/backend/commands/typecmds.c
parent4d5d08c1cd52add02bdfadc00854135a3b6c88f6 (diff)
downloadpostgresql-93a1af0b3f63838774a9e524589344c3d44c867d.tar.gz
postgresql-93a1af0b3f63838774a9e524589344c3d44c867d.zip
Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.
This reverts commit 15bc038f9, along with the followon commits 1635e80d3 and 984c92074 that tried to clean up the problems exposed by bug #14825. The result was incomplete because it failed to address parallel-query requirements. With 10.0 release so close upon us, now does not seem like the time to be adding more code to fix that. I hope we can un-revert this code and add the missing parallel query support during the v11 cycle. Back-patch to v10. Discussion: https://postgr.es/m/20170922185904.1448.16585@wrigleys.postgresql.org
Diffstat (limited to 'src/backend/commands/typecmds.c')
-rw-r--r--src/backend/commands/typecmds.c29
1 files changed, 25 insertions, 4 deletions
diff --git a/src/backend/commands/typecmds.c b/src/backend/commands/typecmds.c
index 29ac5d569d7..8e5134b2c35 100644
--- a/src/backend/commands/typecmds.c
+++ b/src/backend/commands/typecmds.c
@@ -1222,10 +1222,10 @@ DefineEnum(CreateEnumStmt *stmt)
/*
* AlterEnum
- * Adds a new label to an existing enum.
+ * ALTER TYPE on an enum.
*/
ObjectAddress
-AlterEnum(AlterEnumStmt *stmt)
+AlterEnum(AlterEnumStmt *stmt, bool isTopLevel)
{
Oid enum_type_oid;
TypeName *typename;
@@ -1243,8 +1243,6 @@ AlterEnum(AlterEnumStmt *stmt)
/* Check it's an enum and check user has permission to ALTER the enum */
checkEnumOwner(tup);
- ReleaseSysCache(tup);
-
if (stmt->oldVal)
{
/* Rename an existing label */
@@ -1253,6 +1251,27 @@ AlterEnum(AlterEnumStmt *stmt)
else
{
/* Add a new label */
+
+ /*
+ * Ordinarily we disallow adding values within transaction blocks,
+ * because we can't cope with enum OID values getting into indexes and
+ * then having their defining pg_enum entries go away. However, it's
+ * okay if the enum type was created in the current transaction, since
+ * then there can be no such indexes that wouldn't themselves go away
+ * on rollback. (We support this case because pg_dump
+ * --binary-upgrade needs it.) We test this by seeing if the pg_type
+ * row has xmin == current XID and is not HEAP_UPDATED. If it is
+ * HEAP_UPDATED, we can't be sure whether the type was created or only
+ * modified in this xact. So we are disallowing some cases that could
+ * theoretically be safe; but fortunately pg_dump only needs the
+ * simplest case.
+ */
+ if (HeapTupleHeaderGetXmin(tup->t_data) == GetCurrentTransactionId() &&
+ !(tup->t_data->t_infomask & HEAP_UPDATED))
+ /* safe to do inside transaction block */ ;
+ else
+ PreventTransactionChain(isTopLevel, "ALTER TYPE ... ADD");
+
AddEnumLabel(enum_type_oid, stmt->newVal,
stmt->newValNeighbor, stmt->newValIsAfter,
stmt->skipIfNewValExists);
@@ -1262,6 +1281,8 @@ AlterEnum(AlterEnumStmt *stmt)
ObjectAddressSet(address, TypeRelationId, enum_type_oid);
+ ReleaseSysCache(tup);
+
return address;
}