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.Susan
On Thu, Apr 17, 2014 at 8:13 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:
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@xxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote:
>>
>> On 17 Apr 2014, at 2:49, David G Johnston <david.g.johnston@xxxxxxxxx>
>> 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@xxxxxxxxxxxxxx)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>
--
To understand recursion, one must first understand recursion.
