Tom Lane wrote:
[ reincluding the mailing list ]
Michael Milligan mi...@acmeps.com writes:
Okay, it reproduces and surprise surprise nLocks does overflow...
ERROR: lock AccessShareLock on object 16385/16467/0 is already held
lock(0x87408a028) id(16385,16467,0,0,0,1) grantMask(a)
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Michael Milligan mi...@acmeps.com writes:
Okay, it reproduces and surprise surprise nLocks does overflow...
Hah. Okay, that shows that we'd never have reproduced it with a small
test case.
This hasn't been fixed yet, has
Tom Lane wrote:
2008-09-15 21:56 tgl
* src/include/storage/: lock.h (REL8_1_STABLE), lock.h
(REL8_3_STABLE), lock.h (REL8_0_STABLE), lock.h (REL8_2_STABLE),
lock.h: Widen the nLocks counts in local lock tables from int to
int64.
Doh, I didn't see it because I only
Tom Lane wrote:
[ reincluding the mailing list ]
Michael Milligan [EMAIL PROTECTED] writes:
Okay, it reproduces and surprise surprise nLocks does overflow...
ERROR: lock AccessShareLock on object 16385/16467/0 is already held
lock(0x87408a028) id(16385,16467,0,0,0,1) grantMask(a)
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
In any case, now that we know that nLocks overflow is actually possible
within real-world transaction lengths, it'd behoove us to do something
about that in 8.4 or beyond.
Is this a TODO?
Yes, although I'm still waiting for more info
[ reincluding the mailing list ]
Michael Milligan [EMAIL PROTECTED] writes:
Okay, it reproduces and surprise surprise nLocks does overflow...
ERROR: lock AccessShareLock on object 16385/16467/0 is already held
lock(0x87408a028) id(16385,16467,0,0,0,1) grantMask(a) waitMask(0)
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
What was I doing? A large transaction where I was pushing about 20
million rows into
Heikki Linnakangas wrote:
Michael Milligan wrote:
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
What was I doing? A large
Tom Lane wrote:
Michael Milligan [EMAIL PROTECTED] 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
Michael Milligan [EMAIL PROTECTED] writes:
Tom Lane wrote:
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.
Please answer the above question.
And a correction, the transaction that caused
Tom Lane wrote:
Michael Milligan [EMAIL PROTECTED] writes:
Tom Lane wrote:
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.
Please answer the above question.
16385 is the database (db)
Michael Milligan [EMAIL PROTECTED] 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
Tom Lane wrote:
Michael Milligan [EMAIL PROTECTED] 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
Tom Lane wrote:
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?
FWIW, I've used the exact same code against PG 8.2.6 and
Michael Milligan [EMAIL PROTECTED] writes:
FWIW, I've used the exact same code against PG 8.2.6 and have half a
dozen similar transactions that inserted more than 13.5 million rows,
with the largest transaction at a little over 25 million rows inserted
into the email table.
Hmph. That seems
Tom Lane wrote:
Michael Milligan [EMAIL PROTECTED] writes:
FWIW, I've used the exact same code against PG 8.2.6 and have half a
dozen similar transactions that inserted more than 13.5 million rows,
with the largest transaction at a little over 25 million rows inserted
into the email table.
16 matches
Mail list logo
