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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
