Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.de> writes:
>
>>Tom Lane wrote:
>>
>>>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?
>
>
> No, the convention is that you take a lock on the relation you're
> interested in.
So pgAdmin violates the convention, because it doesn't hold a lock an a
table when reengineering its attributes....
Since pg_relation_size is a pure metadata function, I don't think the
convention hits here (.
>
>>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.
>
>
> That's a bit curious. If they just did TRUNCATE then COPY, the commit
> of the TRUNCATE should have released the lock. If the TRUNCATE wasn't
> committed yet, then how are you able to pick up the correct relfilenode
> to look at?
The truncate is buried in a function, I suspect that actually no
truncate happened on an empty table.
Regards,
Andreas
