Re: new --maintenance-db options
От | Amit Kapila |
---|---|
Тема | Re: new --maintenance-db options |
Дата | |
Msg-id | 005001cd5447$d8946ef0$89bd4cd0$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: new --maintenance-db options (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: Amit Kapila <amit.kapila@huawei.com> writes: > [mailto:pgsql-hackers-owner@postgresql.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.
В списке pgsql-hackers по дате отправления: