Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
От | Tom Lane |
---|---|
Тема | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
Дата | |
Msg-id | 4421.1536433875@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: