From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Milligan <milli(at)acmeps(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held |
Date: | 2008-08-30 01:59:42 |
Message-ID: | 6040.1220061582@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Michael Milligan <milli(at)acmeps(dot)com> writes:
> FWIW, I've used the exact same code against PG 8.2.6 and have half a
> dozen similar transactions that inserted more than 13.5 million rows,
> with the largest transaction at a little over 25 million rows inserted
> into the email table.
Hmph. That seems to eliminate the overflow theory, because 8.2 has
essentially the same lock-counting code as 8.3. Unless 8.3 is taking
out the lock a heckuva lot more than 8.2 did, but I can't think of a
reason for that to happen.
Now that we know you can reproduce it, we should think about how to get
some information out. Are you in a position to build a locally modified
Postgres? I could send you a patch to make that particular error report
dump out more information about the lock state, but a patch won't do you
any good if you aren't able to build from source.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Milligan | 2008-08-30 02:38:11 | Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held |
Previous Message | Michael Milligan | 2008-08-30 01:11:29 | Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held |