Robert Haas wrote:
> A colleague at EnterpriseDB today ran into a situation on PostgreSQL
> 9.3.5 where the server went into an infinite loop while attempting a
> VACUUM FREEZE; it couldn't escape _bt_getstackbuf(), and it couldn't
> be killed with ^C. I think we should add a check for interrupts into
> that loop somewhere;
Our design principle in this area is that all loops should have
CHECK_FOR_INTERRUPTS() calls somewhere, so that even if data is horribly
corrupted you can get out of it. (Trivial loops where the exit
condition cannot possibly fail don't need to apply --- surely we don't
need to cope with hardware that makes i+1 go back to i-1 or whatever.)
Therefore I don't think you need to argue very hard in order to add more
interrupt checks if you see a loop that's missing them.
For example, Andres was saying to me just this morning that
GetMultiXactIdMembers is lacking one such check, and I was considering
pushing a patch to add it without any discussion.
> and possibly make some attempt to notice if we've
> been iterating for longer than, say, the lifetime of the universe
> until now.
This I'm not so sure about. Adding extra logic in all nontrivial loops
to detect whether they have been running for "too long" is likely to
cause too much overhead.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services