On 2024-07-31 We 9:14 AM, Joe Conway wrote:
On 7/31/24 05:47, Andrew Dunstan wrote:
On 2024-07-30 Tu 6:51 PM, David Rowley wrote:
On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan<and...@dunslane.net>
wrote:
Fast forward to now. The customer has found no observable ill
effects of
marking these functions leakproof. The would like to know if there is
any reason why we can't mark them leakproof, so that they don't
have to
do this in every database of every cluster they use.
Thoughts?
According to [1], it's just not been done yet due to concerns about
risk to reward ratios. Nobody mentioned any reason why it couldn't
be, but there were some fears that future code changes could yield new
failure paths.
David
[1]https://postgr.es/m/02BDFCCF-BDBB-4658-9717-4D95F9A91561%40thebuild.com
Hmm, somehow I missed that thread in searching, and clearly I'd
forgotten it.
Still, I'm not terribly convinced by arguments along the lines you're
suggesting. "Sufficient unto the day is the evil thereof." Maybe we
need a test to make sure we don't make changes along those lines,
although I have no idea what such a test would look like.
I think I have expressed this opinion before (which was shot down),
and I will grant that it is hand-wavy, but I will give it another try.
In my opinion, for this use case and others, it should be possible to
redact the values substituted into log messages based on some
criteria. One of those criteria could be "I am in a leakproof call
right now". In fact in a similar fashion, an extension ought to be
able to mutate the log message based on the entire string, e.g. when
"ALTER ROLE...PASSWORD..." is spotted I would like to be able to
redact everything after "PASSWORD".
Yes it might render the error message unhelpful, but I know of users
that would accept that tradeoff in order to get better performance and
security on their production workloads. Or in some cases (e.g.
PASSWORD) just better security.
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
