From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Wood <dwood(at)salesforce(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: lock on object is already held |
Date: | 2013-11-19 06:31:51 |
Message-ID: | 30981.1384842711@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Wood <dwood(at)salesforce(dot)com> writes:
> 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.
So let's see the reproducer?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | KONDO Mitsumasa | 2013-11-19 06:54:03 | Re: Logging WAL when updating hintbit |
Previous Message | KONDO Mitsumasa | 2013-11-19 06:08:45 | Re: Improvement of pg_stat_statement usage about buffer hit ratio |