Tom Lane wrote:
> 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.
This would require a lock on pg_class, not table foo, no?
> 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.
Hm, I see the issue. Interesting enough, I *do* see the size growing.
OTOH, when running BEGIN;TRUNCATE against a test table and retrieving
pg_relation_size returns the previous relfilenode and size as expected.
Regards,
Andreas