From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | chris(at)bitmead(dot)com |
Cc: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] backend startup |
Date: | 2000-02-09 07:51:38 |
Message-ID: | 4857.950082698@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2000-02-09 08:22:02 | Re: [HACKERS] TODO item |
Previous Message | Chris Bitmead | 2000-02-09 06:50:13 | backend startup |