Tomas Vondra <tv@xxxxxxxx> writes: > Dne 20.9.2010 15:44, Tom Lane napsal(a): >> I think you're probably hitting a problem with a table being deleted >> while you're scanning pg_class. pg_relation_size() will fail if the >> given OID isn't valid "now" --- but the underlying query returns all >> OIDs that were valid when the transaction or statement snapshot was >> taken. So you have a race condition. >> >> You might consider excluding temp tables from the query, if that's the >> most likely source of the problem. > OK, I'm a bit confused now. So it's not a race condition (i.e. a bug) in > a pg_relation_size but a feature? Well, "feature" is in the eye of the beholder I guess. The race condition is not really avoidable; certainly pg_relation_size() can't do anything to prevent it. And you do *not* want "guaranteed consistent" results; that would mean taking a lock on every table in the system, which would likely result in far more failures, not fewer failures, because of deadlocks. We could prevent your query from failing if we did something like having pg_relation_size() return NULL, rather than throwing an error, if the OID it's given doesn't turn out to correspond to a live table. I'm not sure if that'd be a net improvement or not --- it certainly seems to reduce the system's ability to detect simple errors, and depending on what your query was doing with the results, a NULL could bollix it up in other ways. But IIRC we've done similar things for other system inquiry functions, so maybe it'd be reasonable here too. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
