From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, hlinnaka(at)iki(dot)fi, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proof of concept: standalone backend with full FE/BE protocol |
Date: | 2012-09-03 20:50:22 |
Message-ID: | 25453.1346705422@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 09/03/2012 04:23 PM, Tom Lane wrote:
>> I'm reluctantly coming to the conclusion that we can't pass these
>> parameters through the regular libpq connection string mechanism, and
>> will have to invent something else. That's awfully nasty though;
>> it will pretty much cripple the idea that this would be a simple way to
>> invoke a quasi-embedded variant of Postgres.
> That would be a bit sad. BTW, how would this work for things like
> auto_vacuum, logging_collector and so on?
There's already an "options" connection-string option for passing random
GUC settings through to the connected backend. My original plan was to
just add any such settings to the standalone backend's command line.
In this context that would work for postmaster-level GUCs. However,
if we're going to redesign this then maybe something else is more
appropriate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-03 20:54:23 | Re: Proof of concept: standalone backend with full FE/BE protocol |
Previous Message | Andres Freund | 2012-09-03 20:38:09 | Re: Proof of concept: standalone backend with full FE/BE protocol |