Need a debugging tip or two

Kevin O'Gorman writes:

In any event when I start the backend standalone (i.e. running
the 'postgres -D ....' command, it seems I have to be the root
or postgres root user because of file permissions.

Yup.

But I want access to the database of my normal username, which is
'kevin'.

postgres [options] dbname

Questions: have I identified the problem right? Is that why I
can't see my tables? If so, is there a way to change databases,
given that the \ commands don't work in the backend?

Not sure when a \ command *changed* a database last time.

Or am I just going at this all wrong in some way?

There's probably little reason to start a backend standalone. If you want
to do stock-of-the-trade debugging you simply start a postmaster, then
psql (or whatever floats your boat), and attach gdb to the resulting
backend process.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

There's probably little reason to start a backend standalone. If you want
to do stock-of-the-trade debugging you simply start a postmaster, then
psql (or whatever floats your boat), and attach gdb to the resulting
backend process.

Right, that's what I always do (unless I have to debug a crash at initdb
time :-(). A tip here is that you can even debug backend-startup-time
problems this way, and no you don't have to be superhumanly quick on the
trigger: you set PGOPTIONS="-W n" in the environment of psql. This
will cause an n-second sleep() call very early in the backend startup
process. I find 30 seconds plenty of time to run ps, start gdb, and
attach. You can also throw in things like "-d2" to crank up the
postmaster log level for just the backend under test.

I thought this lore was in the developer's FAQ already, but I don't
see it there at the moment. Bruce, is it lurking someplace else?

regards, tom lane

I see the mention of -w in the main FAQ.

Peter Eisentraut <peter_e@gmx.net> writes:

There's probably little reason to start a backend standalone. If you want
to do stock-of-the-trade debugging you simply start a postmaster, then
psql (or whatever floats your boat), and attach gdb to the resulting
backend process.

Right, that's what I always do (unless I have to debug a crash at initdb
time :-(). A tip here is that you can even debug backend-startup-time
problems this way, and no you don't have to be superhumanly quick on the
trigger: you set PGOPTIONS="-W n" in the environment of psql. This
will cause an n-second sleep() call very early in the backend startup
process. I find 30 seconds plenty of time to run ps, start gdb, and
attach. You can also throw in things like "-d2" to crank up the
postmaster log level for just the backend under test.

I thought this lore was in the developer's FAQ already, but I don't
see it there at the moment. Bruce, is it lurking someplace else?

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026