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 m
e 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.
Regards,
Mike
--
Michael Milligan -> [EMAIL PROTECTED]
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:
>
>&
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
>>> databa
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/16
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
AMEDATALEN 64
+#define NAMEDATALEN 128
/*
* Maximum number of arguments to a function.
This goes along with a UFS block size of 32768.
Regards,
Mike
--
Michael Milligan -> [EMAIL PROTECTED]
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgre
