Re: pg_relation_size locking

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