From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Kong Man <kong_mansatiansin(at)hotmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: search_path not reloaded via unix socket connections |
Date: | 2015-09-18 02:50:51 |
Message-ID: | CAKFQuwbMvZYT1UdWvy4KRDC3N=Eh6xS36xByVUKL8Qv9YL+kRg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thursday, September 17, 2015, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Thursday, September 17, 2015, Kong Man <kong_mansatiansin(at)hotmail(dot)com
> <javascript:_e(%7B%7D,'cvml','kong_mansatiansin(at)hotmail(dot)com');>> wrote:
>
>> Can anybody explain why the search_path setting, with several config
>> reloads, would not change via local connections? We struggled with our
>> production settings on Postgres 9.3 today, only to realize, after a while,
>> that the search_path change actually took effect via TCP/IP, but not unix
>> socket, connections ever since the first reload.
>>
>>
> What Tom said...
>
> Alternatively maybe your Unix socket sessions are long lived but your
> TCP/IP ones are not - potentially going through a pooler that refreshes
> sessions. You need to describe more or provide repeatable evidence if we
> are to conclude that this is anything other than operator error.
>
>
Or not, since it does appear that the reload signal is propagated to active
sessions and take effect after the most recent command finishes.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-18 02:56:17 | Re: search_path not reloaded via unix socket connections |
Previous Message | David G. Johnston | 2015-09-18 02:45:10 | Re: search_path not reloaded via unix socket connections |