Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
