Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held

From: Michael Milligan <milli(at)acmeps(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 00:48:05
Message-ID: 48B898C5.50100@acmeps.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane wrote:
> Michael Milligan <milli(at)acmeps(dot)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(at)acmeps(dot)com

In response to

Browse pgsql-bugs by date

  From Date Subject
Next 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
Previous Message Tom Lane 2008-08-30 00:28:06 Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held