This is interesting... we actually do have a trigger on that table which
inserts a record in a kind of archive table for each deleted record. I
actually forgot about this, good that you reminded me :-)
But then the TRUNCATE worked fine, and the table was actually truncated,
and I'm sure the trigger didn't kick in at all. Is this something
unexpected ?
The trigger itself is a BEFORE DELETE ... FOR EACH ROW trigger, and it's
not deferred. I've checked the table too where the trigger inserts, and
it had indeed a few records, but not as many as the original table had.
That could though come from previous runs...
Thanks,
Csaba.
On Tue, 2005-07-12 at 21:53, Kris Jurka wrote:
> On Tue, 12 Jul 2005, Csaba Nagy wrote:
>
> > I wonder what could cause such an exception (see below). I was executing
> > a "DELETE FROM table_name" command on a table with a lot of records (~
> > 80 million). Now after the fact I realize I should have tried it in psql
> > too to see if it fails there too, but I truncated the tables in the
> > meantime via "TRUNCATE". The only reason I tried to do it via delete is
> > to see how many rows were deleted, but it looks like a bad idea...
> >
> > org.postgresql.util.PSQLException: ERROR: out of memory
>
> This is a backend error message so the fact that you issued the command
> using JDBC is not relevent and it would have failed from psql as well.
> My immediate suspicion was the deferred trigger queue being unable to hold
> an event for each row deleted, but any ON DELETE triggers should have
> prevented TRUNCATE from running. In any case something on the backend
> side is probably using up some memory for each row being deleted.
>
> Kris Jurka
>
