Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Tom Lane wrote:
>> That's only possible if Slony is taking AccessExclusive lock; if so,
>> your gripe is properly directed to the Slony folks, not to
>> pg_relation_size which is acting as a good database citizen should.
> More precisely, it executes TRUNCATE;COPY at the same time; there might
> be additional locks to prevent using the table. Still, I see no reason
> why pg_relation_size shouldn't continue to use SearchSysCache as id did
> for years now. There's no sense in using locking mechanisms on table foo
> while reading file system data; pg_class is sufficient to locate the
> table's files.
The fact that the contrib version did things incorrectly for years is
no justification for not fixing it at the time it's taken into the core.
You have to have a lock to ensure that the table even exists, let alone
that you are looking at the right set of disk files.
In the above example, the contrib code would have not done the right
thing at all --- if I'm not mistaken, it would have kept handing back
the size of the original, pre-TRUNCATE file, since the new pg_class
row with the new relfilenode isn't committed yet. So it wouldn't have
done what you wish anyway.
regards, tom lane