Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id 008f01cd8f04$6c4959c0$44dc0d40$@kapila@huawei.com
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sunday, September 09, 2012 8:46 PM Tom Lane wrote:
Amit kapila <amit.kapila@huawei.com> writes:
>> 1. does this follow the behavior that admin users will not be allowed to
invoke postgres child process?

> That's an interesting question.  I'm not sure if we'd want to disable
> the no-root check on the Unix side, but it might make sense to.  But
> this has no bearing on what libpq does, does it?
 No, it has no bearing with what libpq does. Its only related to postgres
invocation, because as soon as postgres get invoked, it first checks about
root. If we want the root check can be avoided easily by checking argv.

>> 2. to find standalone_backend incase user didn't input, do we need
mechanism similar to getInstallationPaths()?

> No.  There is no reason at all for libpq to think it is part of a
> postgres-supplied program, so it can't use any relative-path tricks,
> even if it had the program's argv[0] which it does not.  Either the
> compiled-in path works, or the user has to give one.

> (But having said that, if Windows provides a way for a DLL to find
> out its own filesystem location, maybe relative path from there would
> work.)

At first, I shall go ahead with the current way (Either the
compiled-in path works, or the user has to give one.).





pgsql-hackers by date:

Previous
From: "Etsuro Fujita"
Date:
Subject: Re: Minor document updates
Next
From: Nils Goroll
Date:
Subject: Re: reviewing the "Reduce sinval synchronization overhead" patch / b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4