Tomas Vondra <tv@fuzzy.cz> 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
