>> 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.
Well, I was thinking about locking the pg_class itself (SHARE ROW
EXCLUSIVE or EXCLUSIVE), but I really am not sure it's a good idea. But
I'm not sure locking a table is different from locking a corresponding
row in the pg_class table - maybe it's the same.
All (or most of) the DDL commands have to modify pg_class at some point,
so I thought that if those commands lock the row (representing a
table/index/...), I could lock the whole table (preventing the DDL from
running).
But I admit this may be a hilariously stupid idea ...
>
> 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.
Hmm, sounds nice. Actually I could create such 'graceful wrapper' on my
own - just catch the exception and return NULL. Right?
Another possible solution is to remove the pg_relation_size from the
SELECT itself execute it in a loop for each of the rows (I have to do a
row-by-row processing anyway, and in case of pg_relation_size the
slowdown should be negligible - I guess).
regards
Tomas