***PUSH***
this bug is really some annoyance if you use automatic build environments.
I'm using phpunit to run tests and as soon as postgres is involved the php
cli environment segfaults at the end. this can be worked around by disabling
ssl but it would be great if the underlying bug got fixed.
PoolSnoopy wrote:
***PUSH***
this bug is really some annoyance if you use automatic build environments.
I'm using phpunit to run tests and as soon as postgres is involved the php
cli environment segfaults at the end. this can be worked around by disabling
ssl but it would be great if the
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.
12 matches
Mail list logo
