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 |