Re: Delayed result from another connection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: SZŰCS Gábor <surrano(at)mailbox(dot)hu>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Delayed result from another connection
Date: 2004-11-04 17:46:28
Message-ID: 26896.1099590388@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-sql

=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?= <surrano(at)mailbox(dot)hu> 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.

> I thought it's something about "35.2 Visibility of Data Changes", but that's
> only for triggers, isn't it?

Nope.

> Also, the rule "query sees results of any
> previously started queries" seems to be invaded: the perform runs right
> before the query for retval.

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.

This has been a sore spot for a long time, but we didn't get consensus
about changing it till recently ...

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2004-11-04 18:23:15 Re: could not find /usr/local/timezone
Previous Message SZŰCS Gábor 2004-11-04 17:19:13 Delayed result from another connection

Browse pgsql-sql by date

  From Date Subject
Next Message Oliver Elphick 2004-11-04 17:46:47 Re: Group by and aggregates
Previous Message Franco Bruno Borghesi 2004-11-04 17:41:55 Re: Group by and aggregates