Hi,
2015-02-20 16:19 GMT+01:00 Tom Lane :
> 2. Semantics. The existing GUC_REPORT variables are all things that
> directly relate to client-visible behavior, eg how values of type
> timestamp will be interpreted and printed. search_path is no such thing,
> so it's hard to make a principled argu
Alexey Klyukin writes:
> On Tue, Dec 2, 2014 at 5:59 PM, Alexander Kukushkin
> wrote:
>> I would like to mark 'search_path' as GUC_REPORT:
> Given this is a one-liner, which doesn't introduce any new code, but
> one flag to the function call, would it be
> possible to review it as a part of the
Hi,
On Tue, Dec 2, 2014 at 5:59 PM, Alexander Kukushkin wrote:
> It's really crazy to keep so many (hundreds) connections to the database and
> it would be much better to have something like pgbouncer in front of
> postgres.
> Right now it's not possible, because pgbouncer is not aware of search
Hi,
As of now postgres is reporting only "really" important variables, but
among them
there are also not so important, like 'application_name'. The only reason
to report
it, was: "help pgbouncer, and perhaps other connection poolers".
Change was introduced by commit: 59ed94ad0c9f74a3f057f359316c84
