Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
