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. The fact that some of the information you care about is
in pg_class is incidental. There is actually stuff going on behind
the scenes to make sure that you get up-to-date info when you do
LockRelation; looking at the pg_class row does *not* by itself guarantee
that. That is, when you SearchSysCache you might get a row that was
good at the start of your transaction but no longer is; relation_open
with a lock guarantees that you get a relation descriptor that is
currently correct.
> 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?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
