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
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 s
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
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
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 (...)
>
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 th
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 tha
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
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?
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 happen. What ob
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 transaction where I was pushing ab
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 t
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 i
***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.
The following bug has been logged online:
Bug reference: 4386
Logged by: David Chen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.9
Operating system: Windows 2003
Description:UNION in Crosstab - missing rows
Details:
Hi,
I wish to report a bug in Crosstab
The following bug has been logged online:
Bug reference: 4387
Logged by: David Chen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.9
Operating system: Windows 2003
Description:UNION in Crosstab - missing rows
Details:
Hi,
I wish to report a bug in Crosstab
>
>
> That part sounds more like the table row is corrupted :-(. If you
> aren't in a position to restore the whole table from backup, you'll
> need to try to identify and wipe out the broken row. Usually zeroing
> its whole page is the easiest way to do this, though you'll want to
> see what els
17 matches
Mail list logo
