Re: pg_relation_size locking
От | Andreas Pflug |
---|---|
Тема | Re: pg_relation_size locking |
Дата | |
Msg-id | 439D9D60.1070101@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: pg_relation_size locking (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_relation_size locking
|
Список | pgsql-hackers |
Tom Lane wrote: > Andreas Pflug <pgadmin@pse-consulting.de> writes: > >>Tom Lane wrote: >> >>>Nonsense. > > >>Ahem. > > >>I'm running Slony against a big replication set. While slon runs COPY >>foo(colnamelist) FROM STDIN, I can't execute pg_relation_size(foo_oid). >>pg_locks will show that the AccessShareLock on foo is not granted. > > > 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. Regards, Andreas
В списке pgsql-hackers по дате отправления: