Re: Commit within a PL/PGSQL procedure - Mailing list pgsql-novice

From Harry Broomhall
Subject Re: Commit within a PL/PGSQL procedure
Date
Msg-id 200306201348.OAA72760@haeb.noc.uk.easynet.net
Whole thread Raw
In response to Re: Commit within a PL/PGSQL procedure  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-novice
Tom Lane writes:
> Harry Broomhall <harry.broomhall@uk.easynet.net> writes:
> > Tom Lane writes:
> >> If so, the most likely explanation is just
> >> that the list of deferred trigger events is getting too large.  This is
> >> a known deficiency on our TODO list (it should be possible to shove the
> >> list out to disk when it gets too large).
>
> >   Any way round this?
>
> Not much :-(.  AFAIR there is no way to get the trigger list to be
> processed while you're inside your function --- you have to return to
> the outer command loop.  (The correctness of this is debatable, but
> that's how things work at the moment.)  So you must either break your
> work into multiple function calls, or not use foreign keys
> while you're building the new table.  You could think about adding
> the FK constraint after you're done inserting data.


  FYI:

  I removed the foreign key from the table definition and tried again
from scratch.

  The function went through with no problems, and 'top' showed that the
backend barely broke sweat, keeping a low memory useage throughout.

  So I've now started to rewrite the thing with this experience in mind.

  Many thanks for your insight and help.

  Regards,
     Harry.


pgsql-novice by date:

Previous
From: Dani Oderbolz
Date:
Subject: Re: Starting psql from Script - how to pass the password?
Next
From: Ennio-Sr
Date:
Subject: Re: Multibyte support and accented characters