On Wed, Apr 25, 2018 at 10:00 AM, Merlin Moncure <mmonc...@gmail.com> wrote: > systems. If we get that tor free I'd be all for it but reading > Robert's email I'm skeptical there are easy wins here. So +1 for > further R&D and -1 for holding things up based on full > transparency...no harm in shooting for that, but let's look at things > from a cost/benefit perspective (IMO).
If we could look at a patch and say "here are the cases that this patch doesn't handle", then we could perhaps decide "we're OK with that, let's ship the feature and document the limitations". But right now it seems to me that we're looking at a feature where no really systematic effort has been made to list all of the potential failure modes, and I'm definitely not on board with the idea of shipping something with a list of cases that are known to work and an unknown list of failure modes. Konstantin has fixed things here and there, but we don't know how much more there is and don't have a well-designed plan to find all such things. Also, I think it's worth considering that the kinds of failures users will get out of anything that's not handled are really the worst kind. If you have an application that relies on session state other than what his patch knows how to preserve, your application will appear to work in light testing because your connection won't actually be swapped out underneath you -- and then fail unpredictably in production when such swapping occurs. There will be no clear way to tell which error messages or behavior differences are due to limitations of the proposed feature, which ones are due to defects in the application, and which ones might be due to PostgreSQL bugs. They'll all look the same, and even experienced PG hackers won't easily be able to tell whether a message saying "cursor XYZ doesn't exist" (or whatever the case is specifically) is because the application didn't create that cursor and nevertheless tried to use it, or whether it's because the connection pooling facility silently through it out. All of that sounds to me like it's well below the standard I'd expect for a core feature. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
