Tom Lane wrote:
> If you don't have a postmaster then the backend is running standalone,
> which is not really the same environment as running in a live
> installation. It's OK for some kinds of debugging but I wouldn't
> trust it an inch for locking or resource-related issues.
Yeh, but for some databases, starting a backend/frontend manually IS
possible for a live installation, and improves performance because you
can run in the one process.
> Say what? I've never yet shut down the postmaster to gdb anything;
> I tell gdb to "attach" to a running backend started by the postmaster.
I guess I'm just too lazy to run ps.
> The major
> advantage of that way of working is you can use a reasonable
> client
> (psql or whatever floats your boat) instead of having to type
> queries
> directly at a backend that has no input-editing or command history
> support.
Sure. But if you could run postgres in one-process mode, the backend
would appear to support history because you could build a backend with
psql built in.
There's also no question about whether you're running in
> a realistic environment or not. Finally, you can fire up an additional
> client+backend to examine the database even when you've got the backend
> under test stopped somewhere (so long as it's not stopped holding a
> spinlock or anything like that). If it weren't for the needs of initdb,
> I think standalone-backend mode would've gone the way of the dodo
> some time ago...
>
> regards, tom lane
>
> ************
--
Chris Bitmead
mailto:chris@bitmead.com
