Dear Tom, Thanks for the explanation, it's more than enough. Some more questions if you don't mind:
----- Original Message ----- From: "Tom Lane" <[EMAIL PROTECTED]> Sent: Thursday, November 04, 2004 6:46 PM > =?iso-8859-2?B?U1rbQ1MgR+Fib3I=?= <[EMAIL PROTECTED]> writes: > > The php connects to the database and updates retval where id=seq. > > It seems to be OK, but the function returns the value of php_retval.retval > > _before_ the call. > > Yes, because your transaction is working with a database snapshot that > predates the other transaction run by the separate PHP connection. Yes, but the snapshot is not constant during a transaction, right? (as my example showed this clearly) ... > Prior to PG 8.0, new snapshots are not taken between commands of a function, > even in READ COMMITTED mode. You could get the behavior you want by > issuing separate interactive commands instead of wrapping the sequence > in a function. ... So if I understood you correctly, it's the function call that sees the old snapshot, and the transaction is more flexible in this issue. right? > > I thought it's something about "35.2 Visibility of Data Changes", but that's > > only for triggers, isn't it? > > Nope. I felt like it's not only for triggers but interpreted the doc as it'd be only for triggers... Having a closer look, discovered that there is another section with this title: "41.4 Visibility of Data Changes" ;) > This has been a sore spot for a long time, but we didn't get consensus > about changing it till recently ... I assume there is no point in begging for a backport... ;) Thanks again, G. %----------------------- cut here -----------------------% \end ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
