Re: BUG #8291: postgres_fdw does not re-read USER MAPING after change. - Mailing list pgsql-bugs

From Albin, Lloyd P
Subject Re: BUG #8291: postgres_fdw does not re-read USER MAPING after change.
Date
Msg-id AE011E7AE62117479360E1E2BD341F4E0933D8@adama.fhcrc.org
Whole thread Raw
In response to Re: BUG #8291: postgres_fdw does not re-read USER MAPING after change.  (Bernd Helmle <mailings@oopsware.de>)
List pgsql-bugs
I realized that postgres_fdw is caching the connection, but when you have e=
xisting items that use the same USER MAPPING and do not cache it such as db=
link you get inconsistency in implementation and this should be avoided.

Lloyd

-----Original Message-----
From: Bernd Helmle [mailto:mailings@oopsware.de]=20
Sent: Wednesday, July 10, 2013 3:34 PM
To: Albin, Lloyd P; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #8291: postgres_fdw does not re-read USER MAPING af=
ter change.



--On 9. Juli 2013 22:05:20 +0000 lalbin@fhcrc.org wrote:

> I have found that if you change the password in the USER MAPPING, that=20
> postgres_fdw will not use it unless the current password fails or you=20
> close and re-open your postgres connection. I found this while testing=20
> to see if the USER MAPPING's supports MD5 passwords and they appeared=20
> to until the next day when I found that they no longer worked because=20
> I had closed and re-opened my connection.
>

Hmm i don't think that's a bug. It's because the postgres_fdw caches the co=
nnection within your local session, reusing it for any subsequent foreign t=
able access.

>
> The second error that I found is in the documentation of ALTER USER
> MAPPING. It incorrectly says how to update a users password.
>
>

It could be misread, i agree. Attached is a small doc patch to address this=
=20
against HEAD.

--=20
Thanks

    Bernd

pgsql-bugs by date:

Previous
From: Bernd Helmle
Date:
Subject: Re: BUG #8291: postgres_fdw does not re-read USER MAPING after change.
Next
From: Alex Hunsaker
Date:
Subject: Re: Unable to handle error in plperl