On Thu, Feb 28, 2019 at 12:05 PM Joe Conway <mail@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
