Problem: Database Lock
----------------------------------


Dear
all
I
am working as a database administrator in a company. Our Database
system is Postgresql-8.3.5 and Application server is Jboss used for
our Adempiere ERP system. This is a web based ERP system. All
servers are running on RHEL.

Now
our system is going to on-line and users are entering old data. So
transactions are occurring very frequently.

Now
I am facing the problem is the application server just hangs at busy
hour and it does not accept any new connection. When I restart the
server (Adempiere, Jboss) it works fine for a few hours and problem
occurs again. When this problem occurs the database server shows the
following log

LOG: process 19181 still waiting for ShareLock on transaction 18025221
after 1002.251 ms
STATEMENT: SELECT CurrentNext, CurrentNextSys, IncrementNo, Prefix, Suffix,
DecimalPattern, AD_Sequence_ID FROM AD_Sequence WHERE Name =3D $1 AND
AD_Client_ID =3D $2 AND IsActive=3D'Y' AND IsTableID=3D'N' AND
IsAutoSequence=3D'Y' ORDER BY AD_Client_ID DESC FOR UPDATE OF
AD_Sequence

LOG: process 19181 acquired ShareLock on transaction 18025221 after
1298870.572 ms
STATEMENT: SELECT CurrentNext, CurrentNextSys, IncrementNo, Prefix, Suffix,
DecimalPattern, AD_Sequence_ID FROM AD_Sequence WHERE Name =3D $1 AND
AD_Client_ID =3D $2 AND IsActive=3D'Y' AND IsTableID=3D'N' AND
IsAutoSequence=3D'Y' ORDER BY AD_Client_ID DESC FOR UPDATE OF
AD_Sequence

and
the lock table informations are as following:
adempiere=3D#
select * from pg_locks where granted =3D 'y' and mode =3D
'ExclusiveLock';
locktype |
database | relation | page | tuple | virtualxid | transactionid |
classid | objid | objsubid | virtualtransaction | pid | mode | gra=
nted
---------------+----------+----------+------+-------+------- -----+---------=
------+---------+-------+----------+--------------------+--- ----+----------=
-----+---------
transactionid | | | | | | 18386552 =
|
| | | 39/1733 | 19196 | ExclusiveLock | t
virtualxid | | | | | 24/1586 | =
|
| | | 24/1586 | 19181 | ExclusiveLock | t
transactionid | | | | | | 18386856 =
|
| | | 24/1586 | 19181 | ExclusiveLock | t
virtualxid | | | | | 39/1733 | =
|
| | | 39/1733 | 19196 | ExclusiveLock | t
transactionid | | | | | | 18386574 =
|
| | | 39/1733 | 19196 | ExclusiveLock | t
transactionid | | | | | | 18386563 =
|
| | | 39/1733 | 19196 | ExclusiveLock | t
transactionid | | | | | | 18386869 =
|
| | | 24/1586 | 19181 | ExclusiveLock | t
virtualxid | | | | | 50/20 | =
|
| | | 50/20 | 19217 | ExclusiveLock | t
transactionid | | | | | | 18386846 =
|
| | | 24/1586 | 19181 | ExclusiveLock | t
tuple |
250427 | 251989 | 209 | 7 | | | | =
| | 24/1586 | 19181 | ExclusiveLock |
t
(10
rows)


adempiere=3D#
select * from pg_locks where granted =3D 'f';
locktype |
database | relation | page | tuple | virtualxid | transactionid |
classid | objid | objsubid | virtualtransaction | pid | mode |
granted
---------------+----------+----------+------+-------+------- -----+---------=
------+---------+-------+----------+--------------------+--- ----+----------=
-+---------
transactionid | | | | | | 18386574 =
|
| | | 24/1586 | 19181 | ShareLock | f
(1
row)

*** Here
you can see that process 19196 have ExclusiveLock on transaction
18386574 and process 19181 is waiting for ShareLock to the same
transaction.

When
I monitor the Application server sessions from Jboss console normally
I can see one of three stats R-Ready, K-Keep Alive and S-Service.
When the application server hangs all sessions goes to Service mode.


Please give me your appropriate and valuable solution in this regard. I am =
eagerly looking forward for your quick reply.
Thanks in advance: --------------------------- Shohorab Hossain

Send instant messages to your online friends http://uk.messenger.yahoo.com

--
Sent via pgsql-docs mailing list (pgsql-docs [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Q2FuIHlvdSBwcm92aWRlIHRoZSBsYXlvdXQgb2YgeW91ciB0YWJsZSBhbmQg
YWxsIGluZGV4ZXMgdGhhdCBhcmUgcHJlc2VudCBvbiBzYWlkIHRhYmxlPw0K
DQpTb3VuZHMgbGlrZSBhIGluY29ycmVjdGx5IGluZGV4ZWQgdGFibGUgcG9z
c2libHkuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBw
Z3NxbC1hZG1pbi1vd25lckBwb3N0Z3Jlc3FsLm9yZyBbbWFpbHRvOnBnc3Fs
LWFkbWluLW93bmVyQHBvc3RncmVzcWwub3JnXSBPbiBCZWhhbGYgT2Ygc2hv
aG9yYWIgaG9zc2Fpbg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTcsIDIw
MDkgMToyNiBQTQ0KVG86IHBnc3FsLWFkbWluQHBvc3RncmVzcWwub3JnOyBw
Z3NxbC1kb2NzQHBvc3RncmVzcWwub3JnOyBwZ3NxbC1nZW5lcmFsQHBvc3Rn
cmVzcWwub3JnDQpTdWJqZWN0OiBbQURNSU5dIFBvc3RncmVzcWwgRGF0YWJh
c2UgTG9jayBQcm9ibGVtDQoNCiAgICANClByb2JsZW06IERhdGFiYXNlIExv
Y2sNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpE
ZWFyDQphbGwNCkkNCmFtIHdvcmtpbmcgYXMgYSBkYXRhYmFzZSBhZG1pbmlz
dHJhdG9yIGluIGEgY29tcGFueS4gT3VyIERhdGFiYXNlDQpzeXN0ZW0gaXMg
UG9zdGdyZXNxbC04LjMuNSBhbmQgQXBwbGljYXRpb24gc2VydmVyIGlzIEpi
b3NzIHVzZWQgZm9yDQpvdXIgQWRlbXBpZXJlIEVSUCBzeXN0ZW0uIFRoaXMg
aXMgYSB3ZWIgYmFzZWQgRVJQIHN5c3RlbS4gIEFsbA0Kc2VydmVycyBhcmUg
cnVubmluZyBvbiBSSEVMLg0KDQpOb3cNCm91ciBzeXN0ZW0gaXMgZ29pbmcg
dG8gb24tbGluZSBhbmQgdXNlcnMgYXJlIGVudGVyaW5nIG9sZCBkYXRhLiBT
bw0KdHJhbnNhY3Rpb25zIGFyZSBvY2N1cnJpbmcgdmVyeSBmcmVxdWVudGx5
Lg0KDQpOb3cNCkkgYW0gZmFjaW5nIHRoZSBwcm9ibGVtIGlzIHRoZSBhcHBs
aWNhdGlvbiBzZXJ2ZXIganVzdCBoYW5ncyBhdCBidXN5DQpob3VyIGFuZCBp
dCBkb2VzIG5vdCBhY2NlcHQgYW55IG5ldyBjb25uZWN0aW9uLiBXaGVuIEkg
cmVzdGFydCB0aGUNCnNlcnZlciAoQWRlbXBpZXJlLCBKYm9zcykgaXQgd29y
a3MgZmluZSBmb3IgYSBmZXcgaG91cnMgYW5kIHByb2JsZW0NCm9jY3VycyBh
Z2Fpbi4gV2hlbiB0aGlzIHByb2JsZW0gb2NjdXJzIHRoZSBkYXRhYmFzZSBz
ZXJ2ZXIgc2hvd3MgdGhlDQpmb2xsb3dpbmcgbG9nDQoNCkxPRzogcHJvY2Vz
cyAxOTE4MSBzdGlsbCB3YWl0aW5nIGZvciBTaGFyZUxvY2sgb24gdHJhbnNh
Y3Rpb24gMTgwMjUyMjENCmFmdGVyIDEwMDIuMjUxIG1zIA0KU1RBVEVNRU5U
OiBTRUxFQ1QgQ3VycmVudE5leHQsIEN1cnJlbnROZXh0U3lzLCBJbmNyZW1l
bnRObywgUHJlZml4LCBTdWZmaXgsDQpEZWNpbWFsUGF0dGVybiwgQURfU2Vx
dWVuY2VfSUQgRlJPTSBBRF9TZXF1ZW5jZSBXSEVSRSBOYW1lID0gJDEgQU5E
DQpBRF9DbGllbnRfSUQgPSAkMiBBTkQgSXNBY3RpdmU9J1knIEFORCBJc1Rh
YmxlSUQ9J04nIEFORA0KSXNBdXRvU2VxdWVuY2U9J1knIE9SREVSIEJZIEFE
X0NsaWVudF9JRCBERVNDIEZPUiBVUERBVEUgT0YNCkFEX1NlcXVlbmNlIA0K
DQpMT0c6IHByb2Nlc3MgMTkxODEgYWNxdWlyZWQgU2hhcmVMb2NrIG9uIHRy
YW5zYWN0aW9uIDE4MDI1MjIxIGFmdGVyDQoxMjk4ODcwLjU3MiBtcyANClNU
QVRFTUVOVDogU0VMRUNUIEN1cnJlbnROZXh0LCBDdXJyZW50TmV4dFN5cywg
SW5jcmVtZW50Tm8sIFByZWZpeCwgU3VmZml4LA0KRGVjaW1hbFBhdHRlcm4s
IEFEX1NlcXVlbmNlX0lEIEZST00gQURfU2VxdWVuY2UgV0hFUkUgTmFtZSA9
ICQxIEFORA0KQURfQ2xpZW50X0lEID0gJDIgQU5EIElzQWN0aXZlPSdZJyBB
TkQgSXNUYWJsZUlEPSdOJyBBTkQNCklzQXV0b1NlcXVlbmNlPSdZJyBPUkRF
UiBCWSBBRF9DbGllbnRfSUQgREVTQyBGT1IgVVBEQVRFIE9GDQpBRF9TZXF1
ZW5jZSANCg0KYW5kDQp0aGUgbG9jayB0YWJsZSBpbmZvcm1hdGlvbnMgYXJl
IGFzIGZvbGxvd2luZzoNCmFkZW1waWVyZT0jDQpzZWxlY3QgKiBmcm9tIHBn
X2xvY2tzIHdoZXJlIGdyYW50ZWQgPSAneScgYW5kIG1vZGUgPQ0KJ0V4Y2x1
c2l2ZUxvY2snOyANCmxvY2t0eXBlICAgIHwNCmRhdGFiYXNlIHwgcmVsYXRp
b24gfCBwYWdlIHwgdHVwbGUgfCB2aXJ0dWFseGlkIHwgdHJhbnNhY3Rpb25p
ZCB8DQpjbGFzc2lkIHwgb2JqaWQgfCBvYmpzdWJpZCB8IHZpcnR1YWx0cmFu
c2FjdGlvbiB8ICBwaWQgIHwgICAgIG1vZGUgICAgfCBncmFudGVkIA0KLS0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0rLS0t
LS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSst
LS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tIA0KdHJhbnNhY3Rpb25pZCB8
ICAgICB8ICAgICAgICAgIHwgICAgICB8ICAgICAgIHwgICAgICAgICAgICB8
ICAgICAgMTgzODY1NTIgfCAgICAgICAgDQp8ICAgICAgIHwgICAgICAgICAg
fCAzOS8xNzMzICAgICAgICAgICAgfCAxOTE5NiB8IEV4Y2x1c2l2ZUxvY2sg
fCB0IA0KdmlydHVhbHhpZCAgICB8ICAgICB8ICAgICAgICAgIHwgICAgICB8
ICAgICAgIHwgMjQvMTU4NiAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAg
DQp8ICAgICAgIHwgICAgICAgICAgfCAyNC8xNTg2ICAgICAgICAgICAgfCAx
OTE4MSB8IEV4Y2x1c2l2ZUxvY2sgfCB0IA0KdHJhbnNhY3Rpb25pZCB8ICAg
ICB8ICAgICAgICAgIHwgICAgICB8ICAgICAgIHwgICAgICAgICAgICB8ICAg
ICAgMTgzODY4NTYgfCAgICAgICAgDQp8ICAgICAgIHwgICAgICAgICAgfCAy
NC8xNTg2ICAgICAgICAgICAgfCAxOTE4MSB8IEV4Y2x1c2l2ZUxvY2sgfCB0
IA0KdmlydHVhbHhpZCAgICB8ICAgICB8ICAgICAgICAgIHwgICAgICB8ICAg
ICAgIHwgMzkvMTczMyAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgDQp8
ICAgICAgIHwgICAgICAgICAgfCAzOS8xNzMzICAgICAgICAgICAgfCAxOTE5
NiB8IEV4Y2x1c2l2ZUxvY2sgfCB0IA0KdHJhbnNhY3Rpb25pZCB8ICAgICB8
ICAgICAgICAgIHwgICAgICB8ICAgICAgIHwgICAgICAgICAgICB8ICAgICAg
MTgzODY1NzQgfCAgICAgICAgDQp8ICAgICAgIHwgICAgICAgICAgfCAzOS8x
NzMzICAgICAgICAgICAgfCAxOTE5NiB8IEV4Y2x1c2l2ZUxvY2sgfCB0IA0K
dHJhbnNhY3Rpb25pZCB8ICAgICB8ICAgICAgICAgIHwgICAgICB8ICAgICAg
IHwgICAgICAgICAgICB8ICAgICAgMTgzODY1NjMgfCAgICAgICAgDQp8ICAg
ICAgIHwgICAgICAgICAgfCAzOS8xNzMzICAgICAgICAgICAgfCAxOTE5NiB8
IEV4Y2x1c2l2ZUxvY2sgfCB0IA0KdHJhbnNhY3Rpb25pZCB8ICAgICB8ICAg
ICAgICAgIHwgICAgICB8ICAgICAgIHwgICAgICAgICAgICB8ICAgICAgMTgz
ODY4NjkgfCAgICAgICAgDQp8ICAgICAgIHwgICAgICAgICAgfCAyNC8xNTg2
ICAgICAgICAgICAgfCAxOTE4MSB8IEV4Y2x1c2l2ZUxvY2sgfCB0IA0Kdmly
dHVhbHhpZCAgICB8ICAgICB8ICAgICAgICAgIHwgICAgICB8ICAgICAgIHwg
NTAvMjAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgDQp8ICAgICAg
IHwgICAgICAgICAgfCA1MC8yMCAgICAgICAgICAgICAgfCAxOTIxNyB8IEV4
Y2x1c2l2ZUxvY2sgfCB0IA0KdHJhbnNhY3Rpb25pZCB8ICAgICB8ICAgICAg
ICAgIHwgICAgICB8ICAgICAgIHwgICAgICAgICAgICB8ICAgICAgMTgzODY4
NDYgfCAgICAgICAgDQp8ICAgICAgIHwgICAgICAgICAgfCAyNC8xNTg2ICAg
ICAgICAgICAgfCAxOTE4MSB8IEV4Y2x1c2l2ZUxvY2sgfCB0IA0KdHVwbGUg
ICAgICAgICB8ICANCjI1MDQyNyB8ICAgMjUxOTg5IHwgIDIwOSB8ICAgICA3
IHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAg
IHwgICAgICAgICAgfCAyNC8xNTg2ICAgICAgICAgICAgfCAxOTE4MSB8IEV4
Y2x1c2l2ZUxvY2sgfA0KdCANCigxMA0Kcm93cykgDQoNCg0KYWRlbXBpZXJl
PSMNCnNlbGVjdCAqIGZyb20gcGdfbG9ja3Mgd2hlcmUgZ3JhbnRlZCA9ICdm
JzsgDQpsb2NrdHlwZSAgICB8DQpkYXRhYmFzZSB8IHJlbGF0aW9uIHwgcGFn
ZSB8IHR1cGxlIHwgdmlydHVhbHhpZCB8IHRyYW5zYWN0aW9uaWQgfA0KY2xh
c3NpZCB8IG9iamlkIHwgb2Jqc3ViaWQgfCB2aXJ0dWFsdHJhbnNhY3Rpb24g
fCAgcGlkICB8ICAgbW9kZSAgICB8DQpncmFudGVkIA0KLS0tLS0tLS0tLS0t
LS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tLSstLS0t
LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tKy0t
LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0t
LS0tLSstLS0tLS0tLS0gDQp0cmFuc2FjdGlvbmlkIHwgICAgIHwgICAgICAg
ICAgfCAgICAgIHwgICAgICAgfCAgICAgICAgICAgIHwgICAgICAxODM4NjU3
NCB8ICAgICAgICANCnwgICAgICAgfCAgICAgICAgICB8IDI0LzE1ODYgICAg
ICAgICAgICB8IDE5MTgxIHwgU2hhcmVMb2NrIHwgZiANCigxDQpyb3cpIA0K
DQoqKiogSGVyZQ0KeW91IGNhbiBzZWUgdGhhdCBwcm9jZXNzIDE5MTk2IGhh
dmUgRXhjbHVzaXZlTG9jayBvbiB0cmFuc2FjdGlvbg0KMTgzODY1NzQgYW5k
IHByb2Nlc3MgIDE5MTgxIGlzIHdhaXRpbmcgZm9yICBTaGFyZUxvY2sgdG8g
dGhlIHNhbWUNCnRyYW5zYWN0aW9uLg0KDQpXaGVuDQpJIG1vbml0b3IgdGhl
IEFwcGxpY2F0aW9uIHNlcnZlciBzZXNzaW9ucyBmcm9tIEpib3NzIGNvbnNv
bGUgbm9ybWFsbHkNCkkgY2FuIHNlZSBvbmUgb2YgdGhyZWUgc3RhdHMgUi1S
ZWFkeSwgSy1LZWVwIEFsaXZlIGFuZCBTLVNlcnZpY2UuDQpXaGVuIHRoZSBh
cHBsaWNhdGlvbiBzZXJ2ZXIgaGFuZ3MgYWxsIHNlc3Npb25zIGdvZXMgdG8g
U2VydmljZSBtb2RlLg0KDQoNClBsZWFzZSBnaXZlIG1lIHlvdXIgYXBwcm9w
cmlhdGUgYW5kIHZhbHVhYmxlIHNvbHV0aW9uIGluIHRoaXMgcmVnYXJkLiBJ
IGFtIGVhZ2VybHkgbG9va2luZyBmb3J3YXJkIGZvciB5b3VyIHF1aWNrIHJl
cGx5LiANClRoYW5rcyBpbiBhZHZhbmNlOiAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0gU2hvaG9yYWIgSG9zc2Fpbg0KDQpTZW5kIGluc3RhbnQgbWVz
c2FnZXMgdG8geW91ciBvbmxpbmUgZnJpZW5kcyBodHRwOi8vdWsubWVzc2Vu
Z2VyLnlhaG9vLmNvbQ0KDQotLSANClNlbnQgdmlhIHBnc3FsLWFkbWluIG1h
aWxpbmcgbGlzdCAocGdzcWwtYWRtaW5AcG9zdGdyZXNxbC5vcmcpDQpUbyBt
YWtlIGNoYW5nZXMgdG8geW91ciBzdWJzY3JpcHRpb246DQpodHRwOi8vd3d3
LnBvc3RncmVzcWwub3JnL21haWxwcmVmL3Bnc3FsLWFkbWluDQoKLS0gClNl
bnQgdmlhIHBnc3FsLWFkbWluIG1haWxpbmcgbGlzdCAocGdzcWwtYWRtaW5A
cG9zdGdyZXNxbC5vcmcpClRvIG1ha2UgY2hhbmdlcyB0byB5b3VyIHN1YnNj
cmlwdGlvbjoKaHR0cDovL3d3dy5wb3N0Z3Jlc3FsLm9yZy9tYWlscHJlZi9w
Z3NxbC1hZG1pbgo=

Next time this is happening join the pg_lock table to the
pg_stat_activity table to see which query is holding the lock for a
bazillion milliseconds, while it's happening. That query / statement
may give you some clue what's wrong.

--
Sent via pgsql-docs mailing list (pgsql-docs [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

The statement that creates lock and waiting is in following. This is from p=
g_stats and pg_stat_activity view.
Here AD_Sequence is a table that maintains sequence number for all database=
objects. It automatically generates primary key value for all table insert=
.. I think it also generates transaction related ID. For that reason it need=
s to update next sequence value for transaction ID.

Statment:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D
SELECT CurrentNext, CurrentNextSys, IncrementNo, Prefix, Suffix, DecimalPat=
tern, AD_Sequence_ID FROM AD_Sequence WHERE Name =3D $1 AND AD_Client_ID =
=3D $2 AND IsActive=3D'Y' AND IsTableID=3D'N' AND IsAutoSequence=3D'Y' ORDE=
R BY AD_Client_ID DESC FOR UPDATE OF AD_Sequence



AD_Sequence Table Definition
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D

adempiere=3D# \d ad_sequence
Table "adempiere.ad_sequence"
Column | Type | Modifiers =

----------------+-----------------------------+------------- ---------------=
--
ad_sequence_id | numeric(10,0) | not null
ad_client_id | numeric(10,0) | not null
ad_org_id | numeric(10,0) | not null
isactive | character(1) | default 'Y'::bpchar
created | timestamp without time zone | not null default now()
createdby | numeric(10,0) | not null
updated | timestamp without time zone | not null default now()
updatedby | numeric(10,0) | not null
name | character varying(60) | not null
description | character varying(255) |
vformat | character varying(40) |
isautosequence | character(1) | not null default 'Y'::bpchar
incrementno | numeric(10,0) | not null
startno | numeric(10,0) | not null
currentnext | numeric(10,0) | not null
currentnextsys | numeric(10,0) | not null
isaudited | character(1) | default 'N'::bpchar
istableid | character(1) | default 'N'::bpchar
prefix | character varying(255) |
suffix | character varying(255) |
startnewyear | character(1) | default 'N'::bpchar
datecolumn | character varying(60) |
decimalpattern | character varying(40) |
Indexes:
"ad_sequence_pkey" PRIMARY KEY, btree (ad_sequence_id)
"ad_sequence_name" UNIQUE, btree (ad_client_id, name)
Check constraints:
"ad_sequence_isactive_check" CHECK (isactive =3D ANY (ARRAY['Y'::bpchar=
, 'N'::bpchar]))
"ad_sequence_isaudited_check" CHECK (isaudited =3D ANY (ARRAY['Y'::bpch=
ar, 'N'::bpchar]))
"ad_sequence_isautosequence_check" CHECK (isautosequence =3D ANY (ARRAY=
['Y'::bpchar, 'N'::bpchar]))
"ad_sequence_istableid_check" CHECK (istableid =3D ANY (ARRAY['Y'::bpch=
ar, 'N'::bpchar]))
"ad_sequence_startnewyear_check" CHECK (startnewyear =3D ANY (ARRAY['Y'=
::bpchar, 'N'::bpchar]))
Foreign-key constraints:
"sequenceclient" FOREIGN KEY (ad_client_id) REFERENCES ad_client(ad_cli=
ent_id) DEFERRABLE INITIALLY DEFERRED
"sequenceorg" FOREIGN KEY (ad_org_id) REFERENCES ad_org(ad_org_id) DEFE=
RRABLE INITIALLY DEFERRED





With Thanks & Regards:
---------------------
Shohorab Hossain



----- Original Message ----
From: Scott Marlowe <scott.marlowe [at] gmail.com>
To: shohorab hossain <shohorab23 [at] yahoo.com>
Cc: pgsql-admin [at] postgresql.org; pgsql-docs [at] postgresql.org; pgsql-general [at] po=
stgresql.org
Sent: Wednesday, November 18, 2009 2:55:25
Subject: Re: [GENERAL] Postgresql Database Lock Problem

Next time this is happening join the pg_lock table to the
pg_stat_activity table to see which query is holding the lock for a
bazillion milliseconds, while it's happening. That query / statement
may give you some clue what's wrong.



Get your preferred Email name!
Now you can [at] ymail.com and [at] rocketmail.com.
http://mail.promotions.yahoo.com/newdomains/aa/

--
Sent via pgsql-docs mailing list (pgsql-docs [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs