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
