Tom Lane wrote:
> Michael Milligan <milli@acmeps.com> writes:
>> Uh oh. This is a first (for me). I got this error on a transaction, it
>> did not crash the server but did abort the transaction (of course).
>
>> ERROR: lock AccessShareLock on object 16385/16467/0 is already held
>
> Huh, that shouldn't happen. What object is that? The 16385 should be
> a database OID, and the 16467 is most likely a table's OID within that
> database.
>
>> What was I doing? A large transaction where I was pushing about 20
>> million rows into two tables using prepared transactions. I have been
>> doing this for some time (over a year) on 8.2.6 without any problems.
>
>> I may be able to reproduce, but the transaction takes a long time to
>> complete... about a day. I'm running it again now.
>
> I wonder if it's possible that you overflowed nLocks in the local lock
> table. There are a lot of other things that likely would break first,
> though, so that doesn't seem very probable.
>
> Is this transaction longer than any comparable one you ever did before?
For 8.3.3, yes. This is only the second such large transaction I've
done on 8.3.3, the first one I did was around 6.7 million rows and it
worked.
And a correction, the transaction that caused this error was inserting
13.5 million rows and failed near the end.
Regards,
Mike
--
Michael Milligan -> milli@acmeps.com