Tom Lane wrote:
What's even more interesting is that there are now three later runs of
HEAD on osprey, and none of them failed. So unless Remi's been fooling
with the environment on that machine, this was a one-shot irreproducible
failure. That's disturbing in a different way ...
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=osprey&br=HEAD
I'm trying to imagine how this diff could come about, and all I can
think is that somehow in this sequence...
--[next line is line 453]------------------------------
-- this should not commit the transaction because the client opened it
SELECT dblink_close('myconn','rmt_foo_cursor');
dblink_close
--------------
OK
(1 row)
-- this should succeed because we have an open transaction
SELECT dblink_exec('myconn','DECLARE xact_test CURSOR FOR SELECT * FROM
foo');
dblink_exec
----------------
DECLARE CURSOR
(1 row)
--[last line is line 465]------------------------------
... if dblink_close() actually (incorrectly) committed the transaction,
I think you would get exactly the diff we got (both hunks).
Now, why that would happen just once, I'm not sure.
That would imply that rconn->newXactForCursor was somehow TRUE, which in
turn implies that in this previous sequence...
--[next line is line 439]------------------------------
-- test opening cursor in a transaction
SELECT dblink_exec('myconn','BEGIN');
dblink_exec
-------------
BEGIN
(1 row)
-- an open transaction will prevent dblink_open() from opening its own
SELECT dblink_open('myconn','rmt_foo_cursor','SELECT * FROM foo');
dblink_open
-------------
OK
(1 row)
--[last line is line 451]------------------------------
...the "BEGIN" statement returned successfully as usual, but for some
reason left (PQtransactionStatus(conn) != PQTRANS_IDLE), causing
dblink_open() to start a transaction and later complete it on line 454.
Is that somehow possible?
Joe
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
