From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Reiner Dassing <dassing(at)wettzell(dot)ifag(dot)de> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Restoring a pg_dump fails with |
Date: | 2001-05-09 14:38:58 |
Message-ID: | 20420.989419138@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Reiner Dassing <dassing(at)wettzell(dot)ifag(dot)de> writes:
> Sorry for coming up again with the same problem:
> COPY FROM fails with "Memory exhausted in AllocSetAlloc(40)"
> CREATE TABLE "wetter" (
> "sensor_id" int4 NOT NULL REFERENCES sensoren_an_orten,
> "epoche" datetime NOT NULL,
> "wert" float4 NOT NULL,
> PRIMARY KEY (sensor_id,epoche));
Ah-hah, so there *is* an AFTER trigger on "wetter", namely the one that
enforces the REFERENCES check.
Probably you are running out of memory for the list of pending trigger
activations; there will be one entry in it per row inserted during the
current transaction, so I can easily believe that you might have a
problem after a couple million rows have been loaded by COPY.
We have a TO-DO item to allow the trigger list to be shoved out to disk
when it gets too long, but that's not done yet ...
I suggest you either break your data load into chunks of no more than
a million rows, or (if you are sure the incoming data is good) disable
the table's triggers during bulk load. For an example of doing that,
look at the script that pg_dump emits for data-only backup.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Heller | 2001-05-09 14:45:32 | 7.1 ... wtf? |
Previous Message | Mauricio de Castro | 2001-05-09 14:24:47 | Books |