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

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Susan Cassidy <susan(dot)cassidy(at)decisionsciencescorp(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Steven Schlansker <steven(at)likeness(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: any way for a transaction to "see" inserts done earlier in the transaction?
Date: 2014-04-17 02:32:06
Message-ID: 534F3D26.7080508@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 04/16/2014 05:24 PM, Susan Cassidy wrote:
> I marked it volatile, and still the next time I call the function after
> the first insert, using the previous new id as as input parameter, it
> still can't "find" the newly inserted id for the next go-round. Nor can
> any regular SELECTs in the main program find it.

To expand on my earlier post and to address all the different scenarios
proposed, it might to be a good idea to expand on what you are logging.
The caveat is whether you are working against a production server or a
development. In the development case you would presumably be able to
more easily limit the scope of what you are observing. In that case
turning up the log_statement to 'all' in postgresql.conf would give you
a picture of what is actually hitting the database. So you could see if
there where multiple connections happening or multiple transactions in a
connection or if different tables where being used, etc. That would help
create some anchor points from which you could backwards engineer to
possible causes.

>
> Susan
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2014-04-17 04:56:05 Re: shared memory allocation - C function
Previous Message Andy Colson 2014-04-17 01:26:07 Re: any way for a transaction to "see" inserts done earlier in the transaction?