Re: new --maintenance-db options

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: "'Robert Haas'" <robertmhaas(at)gmail(dot)com>, "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, "'Pg Hackers'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: new --maintenance-db options
Date: 2012-06-26 13:25:04
Message-ID: 4624.1340717104@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-06-26 13:38:29 Re: [PATCH] lock_timeout and common SIGALRM framework
Previous Message Robert Haas 2012-06-26 12:43:49 Re: [PATCH] lock_timeout and common SIGALRM framework