Re: Restoring a pg_dump fails with

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

In response to

Browse pgsql-admin by date

  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