From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kong Man <kong_mansatiansin(at)hotmail(dot)com>, "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 03:25:04 |
Message-ID: | CAKFQuwbM6vYkpwkxewOKBYp9m4cAhZi29n_+x8PFJyZG9A+QAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thursday, September 17, 2015, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com <javascript:;>> writes:
> > Or not, since it does appear that the reload signal is propagated to
> active
> > sessions and take effect after the most recent command finishes.
>
> Yeah. I had been wondering about long-lived open transactions, but AFAICS
> from the code, backends should re-read the config file at the next client
> command submission, whether inside a transaction block or not. So the
> thing to look for is what might be overriding the config file's value.
>
> In interactive sessions, examining the pg_settings view would be a
> promising way to debug that. I suspect though that the OP is guessing
> about what's happening inside application-driven sessions, where it would
> be hard to do that kind of debugging :-(
>
> regards, tom lane
>
As an aside the alter user/database commands do end up requiring the user
to disconnect and reconnect. Is there a hard limitation why an
administrator can't send some kind of signal to cause a re-read of those by
an active session?
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-18 03:31:00 | Re: search_path not reloaded via unix socket connections |
Previous Message | Adrian Klaver | 2015-09-18 03:21:14 | Re: Broken primary key after backup restore. |