I don't see how. It is a fairly complicated program, and the perl calls are done through an API, which works fine in all other circumstances (I was told I had to use an API, and not use the Perl calls directly).
I moved the code in the function inline into the code, and I still cannot find the newly inserted id the next time through the loop. I think I'm just going to have to commit each time through the loop, although I really hate to. Maybe I can keep a list of the newly inserted rows, and delete them if anything goes wrong later in the loop.
So any chance of a self-contained test case so we're not all chasing our tails?
On Thu, Apr 17, 2014 at 9:06 AM, Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote: > Except for the fact that I get the new id returned from the first insert, > which means that the insert probably did happen. > > Susan > > > On Wed, Apr 16, 2014 at 11:55 PM, Alban Hertroys <haramrae@gmail.com> wrote: >> >> On 17 Apr 2014, at 2:49, David G Johnston <david.g.johnston@gmail.com> >> wrote: >> >> > Robert DiFalco wrote >> >> Two common cases I can think of: >> >> >> >> 1. The PERL framework is only caching the insert and does not actually >> >> perform it until commit is issued. >> > >> > Wouldn't the same mechanism cache the corresponding SELECT? >> >> Not likely, or if it did it wouldn’t be able to know what id was returned >> from the function (which calls nextval(), but that isn’t relevant here since >> it’s marked volatile). >> That makes it a possible scenario for what’s being witnessed here. >> >> Alban Hertroys >> -- >> If you can't see the forest for the trees, >> cut the trees and you'll find there is no forest. >> >> >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general > >
-- To understand recursion, one must first understand recursion.
