| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| 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 02:56:17 |
| Message-ID: | 31161.1442544977@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2015-09-18 03:21:14 | Re: Broken primary key after backup restore. |
| Previous Message | David G. Johnston | 2015-09-18 02:50:51 | Re: search_path not reloaded via unix socket connections |