pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Jeremy Evans <code@jeremyevans.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Date: Sat, 08 Sep 2018 15:11:15 -0400
Message-ID: <4421.1536433875@sss.pgh.pa.us> (raw)
In-Reply-To: <3979.1536433320@sss.pgh.pa.us>
References: <153626613985.23143.4743626885618266803@wrigleys.postgresql.org>
	<20180906215836.GP2726@paquier.xyz>
	<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>

I 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.

Oh, I meant to show the test I used, for the benefit of anyone who
wants to test on other platforms.  Do this (with adjustments to
taste) to set up:

set password_encryption = "scram-sha-256" ;
create user u1 password 'foobar';
create extension postgres_fdw;
create server loopback foreign data wrapper postgres_fdw
  options (host 'localhost', dbname 'postgres');
create user mapping for u1 server loopback
 options (user 'u1', password 'foobar');
grant usage on foreign server loopback to u1;
\c - u1
create table remote (f1 int);
insert into remote values(1),(2);
create foreign table localt (f1 int) server loopback
  options (table_name 'remote');

At this point you should be able to do

select * from localt;

as u1; if not, adjust pg_hba.conf to require a password on localhost
connections.  Once the select works, *leave that session open*, and
in another session do any no-op ALTER on the user mapping, such as

alter user mapping for u1 server loopback options (set user 'u1');

Now, in the first session, repeat

select * from localt;

It'll dump core with a backtrace similar to what Jeremy showed,
if the bug is present.

			regards, tom lane




view thread (33+ messages)  latest in thread

Message-ID: <4421.1536433875@sss.pgh.pa.us>
Permalink:  ../4421.1536433875@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/4421.1536433875@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, code@jeremyevans.net, michael@paquier.xyz, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
  In-Reply-To: <4421.1536433875@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox