Greg Stark <st...@mit.edu> writes: > Fwiw I too think the basic idea of the feature is actually awesome. > There are tons of use cases where you might have one long-lived > transaction working on a dedicated table (or even a schema) that will > never look at the rapidly mutating tables in another schema and never > trigger the error even though those tables have been vacuumed many > times over during its run-time.
I agree that's a great use-case. I don't like this implementation though. I think if you want to set things up like that, you should draw a line between the tables it's okay for the long transaction to touch and those it isn't, and then any access to the latter should predictably draw an error. I really do not like the idea that it might work anyway, because then if you accidentally break the rule, you have an application that just fails randomly ... probably only on the days when the boss wants that report *now* not later. regards, tom lane