| From: | Daniel Wood <dwood(at)salesforce(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | lock on object is already held |
| Date: | 2013-11-19 04:24:01 |
| Message-ID: | CAPweHKfExEsbACRXQTBdu_4QxhHk-Cic_iwmbh5XHo_0Z=Q-1g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Sorry but I don't know how to respond to an old thread I found on
postgresql.org:
http://www.postgresql.org/message-id/20766.1357318482@sss.pgh.pa.us
I presume this is still an open issue. While working on a new feature I
wrote a stress test for it. After fixing my bugs, I couldn't get rid of:
ERROR: lock RowExclusiveLock on object 16384/16393/0 is already held
In addition, with asserts enabled in lock.c I would see Asserts in
UnGrantLock, LockRelease, LockReleaseAll, etc. In one run everything hung
waiting on SQL locks.
The asserts or hang occurs within seconds of running the stress test.
Before I get into the details I want to see if this is something already
being worked on. I can repro it easily in vanilla 9.3.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2013-11-19 04:28:34 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
| Previous Message | Sameer Kumar | 2013-11-19 03:55:14 | Re: Re: Using indexes for ORDER BY and PARTITION BY clause in windowing functions |