> -----Original Message-----
> From: Tom Lane
>
> I wrote:
> > This is a bug in plgsql, or more precisely in SPI, I think. The FOR
> > statement needs to restore its initial value of scanCommandId each time
> > it resumes execution of the SELECT. Seems like that should be done down
> > inside SPI. Comments?
>
> More specifically, the problem is that plpgsql's FOR-over-a-select now
> depends on a SPI cursor, and both SPI cursors and regular cursors are
> broken in this regard. Observe the following misbehavior with a plain
> cursor:
This is a known issue. We should implement INSENSITIVE cursors
to avoid this behavior. The keyword INSENSITIVE is there but isn't
used long. I plan to implement this feature as the first step toward
cross transaction cursors. Saving the xid and commandid in the
portal or snapshot and restoring them at fetch(move) time would
solve it.
regards,
Hiroshi Inoue
