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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: 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