-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Vincent Veyron wrote:
> I suppose you use DBD::Pg, whose current default isolation
> transaction level is ``Serializable''
Just to set the record straight for the archives, DBD::Pg makes
no changes at all to the isolation level. The only wa
My apologies to all, I posted with the wrong id; reposting
--
Regards, Vincent Veyron
http://libremen.com/
Legal case, contract and insurance claim management software
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chan
On Thu, 17 Apr 2014 10:02:00 -0700
Susan Cassidy wrote:
> 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 suppose you use DBD::Pg, whose current default isolation transaction level is
``Serializable''
D
I found the problem, and it is all my fault. I was calling the insert
function with the wrong combination of parameters, so naturally it didn't
find the item. It is working fine now, although I do think I needed to
mark the function as VOLATILE, which I think helped.
Thanks to all for the help.
On Thu, 17 Apr 2014 10:02:00 -0700
Susan Cassidy wrote:
> 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 suppose you use DBD::Pg, whose current default isolation transaction level is
``Serializable''
D
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 ne
Please note that everyone here but you is bottom-posting; please follow the
convention and list standard.
Susan Cassidy-3 wrote
> It is never committed, because the lookup for the insert fails.
So, alter the code so only the first insert happens then stop further
processing and go explore that s
Right. I don't know this code or DBI but many frameworks create a pool of ids
using sequence generators so that they can minimize round trips and know the id
of new records before the are written.
Sent from my iPhone
> On Apr 17, 2014, at 8:06 AM, Susan Cassidy
> wrote:
>
> Except for the f
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
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
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 wrote:
> On 17 Apr 2014, at 2:49, David G Johnston
> wrote:
>
> > Robert DiFalco wrote
> >> Two common cases I can
I suppose it's possible. I've never seen this behavior before, but I don't
think I've ever used this same scenario before. It is slightly unusual.
Susan
On Wed, Apr 16, 2014 at 11:55 PM, Alban Hertroys wrote:
> On 17 Apr 2014, at 2:49, David G Johnston
> wrote:
>
> > Robert DiFalco wrote
>
No, I am doing:
begin transaction
Loop:
Do some selects, including id on second iteration of the inserted id
Do the insert (function call), which also does a select on an id.
Save the newly inserted id for select on the next iteration. This id will
be selected by the insert function on the next it
It is never committed, because the lookup for the insert fails.
Susan
On Wed, Apr 16, 2014 at 5:39 PM, David G Johnston <
david.g.johns...@gmail.com> wrote:
> Susan Cassidy-3 wrote
> > Nor can any regular SELECTs in the main program find it.
>
> Ever?
>
> If this is a same transaction visibilit
I've never had that happen before, and I've used Perl and DBI a lot.
Susan
On Wed, Apr 16, 2014 at 5:34 PM, 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.
> 2. You really ar
On 17 Apr 2014, at 2:49, David G Johnston 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 lik
I'm presuming the OP is using the typical model of:
conn = getConnection()
id = doInsert(conn)
rst = doSelect(conn, id)
doSomething(rst)
conn.commit()
conn.relrease()
Robert DiFalco wrote
> Two common cases I can think of:
>
> 1. The PERL framework is only caching the insert and does not actuall
Susan Cassidy-3 wrote
> Nor can any regular SELECTs in the main program find it.
Ever?
If this is a same transaction visibility issue then when your Perl program
stops you should be able to go find that ID manually to confirm it was
inserted and committed properly. If you still cannot find the I
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.
2. You really are not on the same transaction even though it appears you
are and the transaction isolation is such that you cannot see the insert
until it is f
One possibility is that the INSERT is going to a different table (having the
same name but existing in a different schema) that is visible/default to the
function but not outside of it.
Or the function on the server is not "current" and thus isn't doing what you
think it is.
> I do an insert v
19 matches
Mail list logo
