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
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? |