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 actually > perform it until commit is issued. Wouldn't the same mechanism cache the corresponding SELECT? > 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 fully committed. Doubtful given the way most programs are coded (see assumption above) - the SELECT should be able to see the prior statement results whether committed or not. The only thing I can think of on this line-of-though is that auto-commit is off and while the original INSERT succeeded the transaction it was in was not "COMMIT"ed and the connection used closed/returned-to-pool with an implicit ROLLBACK. Thus when the subsequent SELECT occurred the INSERT never appeared to happen. Not knowing the whether the ID is visible post-program-completion limits the ability to diagnose, though. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/any-way-for-a-transaction-to-see-inserts-done-earlier-in-the-transaction-tp5800432p5800466.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
