]> granicus.if.org Git - postgresql/commit
Fix race condition in enum value comparisons.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 1 Jul 2012 21:12:59 +0000 (17:12 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 1 Jul 2012 21:12:59 +0000 (17:12 -0400)
commitaf4f029675ea2550f12d0b25efb4a673f5c08b08
tree40c6d87d4bce754ec90b318b0f694af1dd5c38ba
parent81aa9610373ab1bfb0b73f9066319186456d4d01
Fix race condition in enum value comparisons.

When (re) loading the typcache comparison cache for an enum type's values,
use an up-to-date MVCC snapshot, not the transaction's existing snapshot.
This avoids problems if we encounter an enum OID that was created since our
transaction started.  Per report from Andres Freund and diagnosis by Robert
Haas.

To ensure this is safe even if enum comparison manages to get invoked
before we've set a transaction snapshot, tweak GetLatestSnapshot to
redirect to GetTransactionSnapshot instead of throwing error when
FirstSnapshotSet is false.  The existing uses of GetLatestSnapshot (in
ri_triggers.c) don't care since they couldn't be invoked except in a
transaction that's already done some work --- but it seems just conceivable
that this might not be true of enums, especially if we ever choose to use
enums in system catalogs.

Note that the comparable coding in enum_endpoint and enum_range_internal
remains GetTransactionSnapshot; this is perhaps debatable, but if we
changed it those functions would have to be marked volatile, which doesn't
seem attractive.

Back-patch to 9.1 where ALTER TYPE ADD VALUE was added.
src/backend/utils/cache/typcache.c
src/backend/utils/time/snapmgr.c