Re: new --maintenance-db options

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
>>> The implementation I've wanted to see for some time is that you can
>>> start a standalone backend, but it speaks FE/BE protocol to its caller
>>> (preferably over pipes, so that there is no issue whatsoever of where
>>> you can securely put a socket or anything like that).

>> Can't it be done like follow the FE/BE protocol, but call directly the
>> server API's
>> at required places.

> That wouldn't be easier, nor cleaner, and it would open us up to
> client-induced database corruption (from failure to follow APIs, crashes
> in the midst of an operation, memory stomps, etc). We decided long ago
> that we would never support truly embedded operation in the sense of PG
> executing in the client's process/address space.

Okay.

> I like the design
> suggested above because it has many of the good properties of an
> embedded database (in particular, no need to manage or contact a server)
> but still keeps the client code at arm's length.

In such a case will that standalone backend manage other processes like (wal
writer, checkpoint, ...) or no background processes like in current --single
mode.

Can there be any performance advantage also in such a mode as compare to
current when client and server on same m/c and uses Domain Socket?

With Regards,
Amit Kapila.