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?
regards, tom lane
