Steve

Thanks to reply

This is for the process with pid 25021



Without joining and using the following query I see the tablenames (the 14 first lines)


biopacs_production=# select locktype, relation::regclass as relname,mode,granted from pg_locks where transaction is not null and pid=25021 order by relname limit 14;
 locktype |                                   relname                                    |      mode       | granted
----------+------------------------------------------------------------------------------+-----------------+---------
 relation | pg_class                                                                     | AccessShareLock | t
 relation | pg_namespace                                                                 | AccessShareLock | t
 relation | pg_class_oid_index                                                           | AccessShareLock | t
 relation | _sysrep._unittesting_key_seq                                                 | AccessShareLock | t
 relation | _sysrep.sequence_test                                                        | AccessShareLock | t
 relation | globaldata."Address_AddressID_seq"                                           | AccessShareLock | t
 relation | globaldata."AnonymizationRuleAssociation_AnonymizationRuleAssociationID_seq" | AccessShareLock | t
 relation | globaldata."AnonymizationRule_AnonymizationRuleID_seq"                       | AccessShareLock | t
 relation | globaldata."Attachment_AttachmentID_seq"                                     | AccessShareLock | t
 relation | globaldata."AuditAddress_ID_seq"                                             | AccessShareLock | t
 relation | globaldata."AuditAnonymizationRule_ID_seq"                                   | AccessShareLock | t
 relation | globaldata."AuditAnonymizationRuleAssociation_ID_seq"                        | AccessShareLock | t
 relation | globaldata."AuditAttachment_ID_seq"                                          | AccessShareLock | t
 relation | globaldata."AuditAttachmentLocation_ID_seq"                                  | AccessShareLock | t
(14 rows)





________________________________
 De : Steve Singer <ssinger at ca.afilias.info>
À : David TECHER <davidtecher at yahoo.fr> 
Cc : Slony Hackers <slony1-hackers at lists.slony.info> 
Envoyé le : Mercredi 4 avril 2012 17h25
Objet : Re: [Slony1-hackers] CreateEvent and Lokcs on replicated objects
 
On 12-04-04 06:25 AM, David TECHER wrote:
> Hi


I can't think of an obvious reason why a generic SYNC event would get a 
lock on all of your tables. I don't think the SYNC event looks at 
replicated tables .

What transactions are holding the locks?  You should be able to see this 
in your pg_locks output (joining back to pg_class to get the tablenames 
from the oids)






>
> I am using Slony 1.2.22
>
> I've noticed that when a CreateEvent occurs
>
> biopacs_production=# select * from pg_stat_activity where procpid=25021;
> datid | datname | procpid | usesysid | usename | current_query | waiting
> | query_start | backend_start | client_addr | client_port
> -------+--------------------+---------+----------+--------------+----------------------------------------------------------------+---------+----------------------------------+----------------------------------+-------------+-------------
> 16387 | biopacs_production | 25021 | 10 | enterprisedb | select
> "_biocluster".createEvent('_biocluster', 'SYNC', NULL); | f | 04-APR-12
> 06:22:24.804654 -04:00 | 01-APR-12 06:53:33.363283 -04:00 | 127.0.1.1 |
> 42050
> (1 row)
>
>
> Then by querying pg_locks I've noticed that there is a 'AccessSharelock'
> on all replicated objects (tables and sequences).
>
> It is normal?
>
> Since our database used intensive CPU (high load) I asked myself if it
> could explained my issue.
>
> Thanks for letting me know.
>
> Kind regards.
>
> David.
>
>
>
> _______________________________________________
> Slony1-hackers mailing list
> Slony1-hackers at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-hackers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-hackers/attachments/20120404/ad988d43/attachment.htm