X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 5725B3A3AED for ; Fri, 5 Nov 2004 13:30:15 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 05282-02 for ; Fri, 5 Nov 2004 13:30:03 +0000 (GMT) Received: from fe07.axelero.hu (fe07.axelero.hu [195.228.240.95]) by svr1.postgresql.org (Postfix) with ESMTP id AF9543A3CD1 for ; Fri, 5 Nov 2004 13:30:04 +0000 (GMT) Received: from fe07 (localhost-02 [127.0.2.1]) by fe07.axelero.hu (8.12.11/8.12.11) with SMTP id iA5DU30b078035 for ; Fri, 5 Nov 2004 14:30:04 +0100 (CET) Received: from fe07.axelero.hu [127.0.2.1] via SMTP gateway by fe07 [195.228.240.95]; id A0300E2B80C at Fri, 05 Nov 2004 14:30:02 +0100 Received: from fejleszt4 (121-248-182-81.adsl-fixip.axelero.hu [81.182.248.121]) by fe07.axelero.hu (8.12.11/8.12.11) with SMTP id iA5DU0sI077456 for ; Fri, 5 Nov 2004 14:30:01 +0100 (CET) Message-ID: <011201c4c33b$7bd722c0$0403a8c0@fejleszt4> From: =?iso-8859-2?B?U1rbQ1MgR+Fib3I=?= To: References: <012601c4c292$6804b810$0403a8c0@fejleszt4> <26896.1099590388@sss.pgh.pa.us> Subject: Re: Delayed result from another connection Date: Fri, 5 Nov 2004 14:29:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-RAVMilter-Version: 8.4.3(snapshot 20030217) (fe07.axelero.hu) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200411/41 X-Sequence-Number: 19360 Dear Tom, Thanks for the explanation, it's more than enough. Some more questions if you don't mind: ----- Original Message ----- From: "Tom Lane" Sent: Thursday, November 04, 2004 6:46 PM > =?iso-8859-2?B?U1rbQ1MgR+Fib3I=?= 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