Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held
От | Tom Lane |
---|---|
Тема | Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held |
Дата | |
Msg-id | 6040.1220061582@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held (Michael Milligan <milli@acmeps.com>) |
Ответы |
Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0
is already held
|
Список | pgsql-bugs |
Michael Milligan <milli@acmeps.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
В списке pgsql-bugs по дате отправления: