Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held
От | Michael Milligan |
---|---|
Тема | Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held |
Дата | |
Msg-id | 48B898C5.50100@acmeps.com обсуждение исходный текст |
Ответ на | Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Tom Lane wrote: > Michael Milligan <milli@acmeps.com> writes: >> Tom Lane wrote: >>> Once you've determined which table the error message is talking about, >>> please show us what the transaction does with that table. > >> You mean like: > >> BEGIN; >> PREPARE msg (...) INSERT INTO email VALUES (...); >> EXECUTE msg (...) >> EXECUTE msg (...) >> EXECUTE msg (...) >> EXECUTE msg (...) >> ... repeated millions of times >> COMMIT; > > What I'm wondering about is the sequence of operations that are executed > per row. Could it be long enough that the email table is being touched > by more than 2 billion separate SQL operations within the transaction? I can't imagine that, but then again, I'm not a PostgreSQL internals expert either. The partitioned email tables have indexes on them, but in this part of the transaction, all I'm doing is EXECUTEs where the prepared statement is INSERTing a single row. Nothing else fancy with the email table is going on. There are other things going on with values being stored to TEMP tables within the same transaction, would those count toward the 2 billion? I ran the transaction again and it failed again, so it is reproducable. I'm going to try it with a much smaller dataset and see what happens. Regards, Mike -- Michael Milligan -> milli@acmeps.com
В списке pgsql-bugs по дате отправления: