On Thu, Feb 28, 2019 at 12:05 PM Joe Conway <m...@joeconway.com> wrote: > I think that would affect the server logs too, no? Worth thinking about > though...
Yeah, I suppose so, although there might be a way to work around that. > Also manually marking all functions leakproof is far less convenient > than turning off the check as this patch effectively allows. You would > want to keep track of the initial condition and be able to restore it if > needed. Doable but much uglier. Perhaps we could tolerate a hook that > would allow an extension to do this though? Yeah, possibly. I guess we'd have to see how ugly that looks, but.... > Again, remember that the actual messages are available in the server > logs. The presumption is that the server logs are kept secure, and it is > ok to leak information into them. How the customer does or does not > decide to pass some of that information on to a support group becomes a > problem to deal with on a case by case basis. > > Also, as mentioned up-thread, in many cases there is or should be a > non-production instance available to use for reproducing problems to > debug them. Presumably the data on such a system is faked or has already > been cleaned up for a wider audience. Mmmph. If your customers always have a non-production instance where problems from production can be easily reproduced, your customers are not much like our customers. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
