Обсуждение: backend startup
Is there any particular reason why a backend has to be started by the postmaster unless it is the only backend running (in debug mode) ? I'm thinking here that (a) It would be more convenient to debug if you didn't have to shut down the postmaster to run gdb postgres and... (b) If that were the case you be part-way to implementing a single-process database option like some databases have. What are the issues? Finding the shared memory etc perhaps?
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> Is there any particular reason why a backend has to be started by the
> postmaster unless it is the only backend running (in debug mode) ?
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.
> (a) It would be more convenient to debug if you didn't have to shut down
> the postmaster to run gdb postgres and...
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.
(See thread a couple weeks ago on exactly this point.) 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. 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
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
At 05:50 PM 2/9/00 +1100, Chris Bitmead wrote: > >Is there any particular reason why a backend has to be started by the >postmaster unless it is the only backend running (in debug mode) ? > >I'm thinking here that > >(a) It would be more convenient to debug if you didn't have to shut down >the postmaster to run gdb postgres and... > >(b) If that were the case you be part-way to implementing a >single-process database option like some databases have. I can see where (a) is true, but who really cares about (b) any more? NT, BSD, or Linux on a several hundred dollar PC has no problem with dozens of processes... - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
Don Baccus wrote: > > At 05:50 PM 2/9/00 +1100, Chris Bitmead wrote: > > > >Is there any particular reason why a backend has to be started by the > >postmaster unless it is the only backend running (in debug mode) ? > > > >I'm thinking here that > > > >(a) It would be more convenient to debug if you didn't have to shut down > >the postmaster to run gdb postgres and... > > > >(b) If that were the case you be part-way to implementing a > >single-process database option like some databases have. > > I can see where (a) is true, but who really cares about (b) any > more? NT, BSD, or Linux on a several hundred dollar PC has no problem > with dozens of processes... Well there is socket overhead and extra context-switching time.
At 09:32 AM 2/10/00 +1100, Chris Bitmead wrote: >> I can see where (a) is true, but who really cares about (b) any >> more? NT, BSD, or Linux on a several hundred dollar PC has no problem >> with dozens of processes... >Well there is socket overhead and extra context-switching time. Given how expensive the basic RDBMS structure is, I imagine this is a bit like worrying about the fact that the bugs on my windshield increase drag and decrease my gas mileage. I mean ... this is undoubtably true, but really pales in comparison to other factors that impact my gas mileage. Now, if you got rid of all the baggage associated with sharing buffers, locking, and all the rest that goes with the multiple process model used by Postgres you might end up with a single-process/single client version that is noticably faster. But just getting rid of the kernel overhead of two processes talking to each other isn't going to get you much, I don't think. You might be able to measure it for something like "select 1", but real queries on real databases? I find it hard to believe. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
Don Baccus wrote: > > At 09:32 AM 2/10/00 +1100, Chris Bitmead wrote: > > >> I can see where (a) is true, but who really cares about (b) any > >> more? NT, BSD, or Linux on a several hundred dollar PC has no problem > >> with dozens of processes... > > >Well there is socket overhead and extra context-switching time. > > Given how expensive the basic RDBMS structure is, I imagine this > is a bit like worrying about the fact that the bugs on my windshield > increase drag and decrease my gas mileage. > > I mean ... this is undoubtably true, but really pales in comparison > to other factors that impact my gas mileage. Well I don't know, but I know VERSANT for example provides a lib1p.so and a lib2p.so, and I know they make sure to link against 1p.so for benchmarks. > Now, if you got rid of all the baggage associated with sharing buffers, > locking, and all the rest that goes with the multiple process model > used by Postgres you might end up with a single-process/single client > version that is noticably faster. Well, I'm not talking about a single client version. That would be of dubious value. > But just getting rid of the kernel overhead of two processes talking > to each other isn't going to get you much, I don't think. You might > be able to measure it for something like "select 1", but real queries > on real databases? I find it hard to believe.