Thread: Delayed result from another connection

Dear Gurus,

I have a strange scenario that doesn't seem to work flawlessly. I think I
can produce a full working example if needed.

We use postgresql 7.4.5
It's something like this:

%----------------------- cut here -----------------------%
CREATE TABLE php_retval(id serial PRIMARY KEY, retval varchar);
CREATE FUNCTION php_run(int, varchar) RETURNS varchar AS '
declare   seq ALIAS FOR $1;   php ALIAS FOR $2;   ret varchar;
begin   perform php_run_c(php, seq);   ret := retval from php_retval where id = seq;   return ret;
end;'   LANGUAGE 'plpgsql' VOLATILE STRICT;
%----------------------- cut here -----------------------%

Now, this calls a c (SPI) function that calls system() to execute "php -q"

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. However, the php does the update. If I repeat the
function call in the transaction, the new result is returned:

%----------------------- cut here -----------------------%
UPDATE php_retval SET retval='nothing' WHERE id=1;
BEGIN;   SELECT php_run(1, 'test.php');   --> 'nothing'   SELECT php_run(1, 'test.php');   --> '3', the right value
END;
%----------------------- cut here -----------------------%

I thought it's something about "35.2 Visibility of Data Changes", but that's
only for triggers, isn't it? Also, the rule "query sees results of any
previously started queries" seems to be invaded: the perform runs right
before the query for retval.

Any ideas, explanations, clarifications, points to earlier discussions, rtfm
etc?

TIA,
G.
%----------------------- cut here -----------------------%
\end

SZŰCS Gábor <surrano@mailbox.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

Dear Tom,

Thanks for the explanation, it's more than enough. Some more questions if
you don't mind:

----- Original Message ----- 
From: "Tom Lane" <tgl@sss.pgh.pa.us>
Sent: Thursday, November 04, 2004 6:46 PM


> SZŰCS Gábor <surrano@mailbox.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.

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

SZŰCS Gábor <surrano@mailbox.hu> writes:
> From: "Tom Lane" <tgl@sss.pgh.pa.us>
>> 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?

In pre-8.0 releases, the snapshot only advances between interactive
commands, not between commands of a function; so you can't see the
results of other transactions that commit after the function starts.
        regards, tom lane