On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers