Date: Sat, 8 Sep 2018 12:39:14 -0700
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>,
	Jeremy Evans <code@jeremyevans.net>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Message-ID: <20180908193914.GI32058@paquier.xyz>
References: <20180906222843.GF17425@jeremyevans.local>
 <20180907165103.GH17425@jeremyevans.local>
 <20180907175518.GI17425@jeremyevans.local>
 <20180907181522.GB32058@paquier.xyz>
 <20016.1536351535@sss.pgh.pa.us>
 <20180907204403.GC32058@paquier.xyz>
 <16558.1536407783@sss.pgh.pa.us>
 <18398.1536410055@sss.pgh.pa.us>
 <87o9d8rv08.fsf@news-spur.riddles.org.uk>
 <3979.1536433320@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="9s922KAXlWjPfK/Q"
Content-Disposition: inline
In-Reply-To: <3979.1536433320@sss.pgh.pa.us>
Precedence: bulk


--9s922KAXlWjPfK/Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 08, 2018 at 03:02:00PM -0400, Tom Lane wrote:
> I tried setting up a scram-auth-based postgres_fdw connection on
> my RHEL6 box and forcing it through the questionable code path
> by issuing a dummy ALTER USER MAPPING command from another session.
> It worked fine, so the problem doesn't seem to be present on Linux.
>=20
> Repeating the same thing on a nearby OpenBSD 6.0 image ... kaboom!
> It fails exactly as Jeremy describes.  Furthermore, I can confirm
> that the attached patch fixes it.

That's not good!  I have tried the report on Linux only, with pgbench -C
doing many foreign scans through postgres_fdw which connects to the
remote using SCRAM authentication, and this was stable.  Anything newer
than ec136d19 is impacted.  I am surprised this has not been seen
earlier to be honest.

> I wonder which other platforms we have that behave like this?
> And how come we've not seen symptoms before?  It's hard to believe
> that src/common/saslprep.c is the only thing libpq imports
> that has FRONTEND-vs-not-FRONTEND behavior differences.

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?  Have you
tried to stress it more with pgbench -C doing only foreign scans and
dozens of clients running in parallel?
--
Michael

--9s922KAXlWjPfK/Q
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAluUJWIACgkQnvQgOdby
QH3iOhAAgNiCyEfVjTsnK1NKOz/E43mwdJwae9JvrxuGqv39hqTCwcjs3MBbd8r0
Ij2SUFioyp4EIlEVNQJJQgweAmHLGuPDOp+wWmnNX2vmn+Bl8oqFD8TkiY0x5bQM
R4ro2YfJrrjRkPTnnk6mI7N0n4fIEC6HMAdg7TNi0DQq7fad6BA2aIvy9PqnUya/
mxKASYrzi/h0UDVBOJc66Ylh6h0KYcvjpPfYhVwMbYk5FC5EmQd6405bp8Ai4IAt
r5pQVMd6f3T0y93BfLmgWP+XaGyNlM1HFix85xRPi0skR/WZ2ehL0j8QF6c3mT3q
B1bk4PcN7tawlN1M+vu0/7Xa7CxcZAHFDiYD8k1z6j3A6yi1RXnNdNyJqLURKtMH
JMR2+JJEIAtAGdd/PLDQEjmImrltuQ2/wfB5099TLbIU17+Q181lkI2aT4qOL+dK
wlEzIC7mPtlm47lAhgH+U1skvt+j7VWOJqALumyjyTTjoQJyA8bBLQH9s1R8+ftY
zAuhLQ3XmDHi3gggT4RF+YKtOxVuCg4/GEfO1X9sXImvmd1qleBrQB3yGkyV+LEj
ZaZp62IzE4lBAwE9z1UAH2M3LlJ/lD96BPLLG8YNX1UiKZPY9qmALR471pVO41qD
nVqPcP1V/edCT+2Xo4n0NdZvI2BihXEjg/aLCTeiBDdpyQFCJPE=
=p3uS
-----END PGP SIGNATURE-----

--9s922KAXlWjPfK/Q--