On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber <phil@omniti.com> wrote:
> Is SnapshotAny the snapshot I should be using? It seems to get the
> correct results. I can drop a table and I get NULL. Then after a
> vacuumdb it returns an error.
The suggestion on the original thread was to use SnapshotDirty or the
caller's MVCC snapshot. SnapshotAny doesn't seem like a good idea.
We don't want to include rows from, say, transactions that have rolled
back. And SnapshotAny rows can stick around for a long time - weeks,
months. If a table is only occasionally updated, autovacuum may not
process it for a long time.
On the other hand, I think using SnapshotDirty is going to work out so
well: isn't there a race condition? The caller's MVCC snapshot seems
better, but I still see pitfalls. Who is to say that the immediate
caller has the same snapshot as the scan? I'm thinking of cases
involving things like CTEs and nested function calls.
I'm wondering if we oughta just return NULL and be done with it. If
SELECT select 1241241241::regclass doesn't choke, I'm not sure select
pg_relation_size(1241241241) ought to either. It's not like the user
is going to see NULL and have no clue that the relation wasn't found.At the very worst they might think it's empty.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
