why does enum_endpoint call GetTransactionSnapshot()? - Mailing list pgsql-hackers

From Robert Haas
Subject why does enum_endpoint call GetTransactionSnapshot()?
Date
Msg-id CA+TgmoZvyu-_McgPYiH=AjpPDCRfPRA9vrcKv_Z26Nqyk0UNiw@mail.gmail.com
Whole thread Raw
Responses Re: why does enum_endpoint call GetTransactionSnapshot()?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
The comments say say that we must use "an" MVCC snapshot here, but
they don't explain why it should be one retrieved via
GetTransactionSnapshot() rather than GetActiveSnapshot() or
GetLatestSnapshot() or GetCatalogSnapshot().  The comments also refer
the reader to catalog/pg_enum.c for more details, but the only
information I can find in pg_enum.c just says that if reading multiple
values for the same enum, the same snapshot should be used for all of
them.  That's not an issue here, since we're only reading one value.
The behavior can't be chalked up to a desire for MVCC compliance,
because it updates the transaction snapshot mid-query:

rhaas=# create type color as enum ('red');
CREATE TYPE
rhaas=# select distinct enum_last(NULL::color) from
generate_series(1,1000000) g;enum_last
-----------red
(1 row)
rhaas=# select distinct enum_last(NULL::color) from
generate_series(1,1000000) g;
-- while this is running, do "alter type color add value 'green';" in
another window
enum_last
-----------redgreen
(2 rows)

I think this is probably a holdover from before the death of
SnapshotNow, and that we should just pass NULL to
systable_beginscan_ordered() here, the same as we do for other catalog
accesses.  Barring objections, I'll go make that change.

If there's some remaining reason for doing it this way, we should add
comments explaining what it is.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: restrict global access to be readonly
Next
From: Heikki Linnakangas
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0