This situation falls from a problem that we noticed a mighty long time ago in Slony, where the set of XIDs outstanding gets very large, and, attendant to that, the set of "action id" values by which tuples are being filtered, gets correspondingly large.
It happens when there is a long pause in application of replication data, and is commonly the consequence of setting up replication on a very large data table that takes a long time for the initial data copy.
At the time, Neil Conway observed this query breakage with a query that was roughly 640K in size, from whence fell jokes to the effect, "who would ever need a query larger than 640K?"
The resolution that I introduced at the time was to write a little parser that would recognize sequences of adjacent values and merge them into "BETWEEN A and B" clauses, which would bring the query size back to a reasonable size.
Joking about "640K" aside, it doesn't seem reasonable to expect a truly enormous query as is generated by the broken forms of this logic to turn out happily. I'd rather fix Slony (as done in the above patch).
