Re: Re: any way for a transaction to "see" inserts done earlier in the transaction?

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.

Thanks,
Susan

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