aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-03-24 14:30:29 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-03-24 14:30:29 -0400
commitaf1d3958432c9438c4ec168bd16bdf9a91066a9f (patch)
tree649f70dba79d437b2de842a592da53575930b832 /doc/src
parentd37e0d0c50ee560fa2e7dc2a4dc904a885957985 (diff)
downloadpostgresql-af1d3958432c9438c4ec168bd16bdf9a91066a9f.tar.gz
postgresql-af1d3958432c9438c4ec168bd16bdf9a91066a9f.zip
Allow more cases to pass the unsafe-use-of-new-enum-value restriction.
Up to now we've rejected cases like BEGIN; CREATE TYPE rainbow AS ENUM (); ALTER TYPE rainbow ADD VALUE 'red'; -- use the value 'red', perhaps in a constraint or index COMMIT; The concern is that the uncommitted enum value 'red' might get into an index and then break the index if we roll back the ALTER ADD. If the ALTER is in the same transaction as the CREATE then it's really perfectly safe, but we weren't taking the trouble to identify that. pg_dump in binary-upgrade mode will emit enum definitions that look like the above, which up to now didn't fall foul of the unsafe-usage check because we processed each restore command as a separate transaction. However an upcoming patch proposes to bundle the restore commands into large transactions to reduce XID consumption during pg_upgrade, and that makes this behavior a problem. To fix, remember the OIDs of enum types created in the current transaction, and allow use of enum values that are added to one later in the same transaction. To do this fully correctly in the presence of subtransactions, we'd have to track subtransaction nesting level of the CREATE and do maintenance work at every subsequent subtransaction exit. That seems expensive, and we don't need it to satisfy pg_dump's usage. Hence, apply the additional optimization only when the CREATE and ALTER are at outermost transaction level. Patch by me, reviewed by Andrew Dunstan Discussion: https://postgr.es/m/1548468.1711220438@sss.pgh.pa.us
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions