Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> libpq is quite particular in the fact that it compiles directly with
> stuff in src/common, src/port, etc. I think that the same problem
> exists for pg_md5_encrypt(). So I like the solution proposed. I guess
> you have made sure that postgres_fdw becomes stable this way?

It still passes its regression test with the patch, on my OpenBSD image.
See also the reproducer procedure I posted.

The bigger issue we need to worry about is whether applying version-script
symbol filtering would cause issues for third-party code that might be
relying on being able to access libpq "internal" functions on *BSD.
I don't have much sympathy for that and wouldn't hesitate to apply the
filtering in HEAD and v11, but maybe in v10 we ought not do that.

We could possibly band-aid around the problem in v10 by changing the SCRAM
support functions so that they always malloc, never palloc, whether in
frontend or not. That might lead to memory leaks in the backend case,
but I'm not sure how much we care about memory leaks during backend
authentication failures --- the process would exit shortly anyway.
I've not investigated this idea any further than thinking of it, though,
and I'm not sure it's worth the trouble to avoid symbol filtering.

I'm inclined to add a test in src/test/authentication that exercises
this problem, in hopes of finding out from the buildfarm whether we
have any other platforms with the issue.

regards, tom lane