Thread: Does "postmaster -i"...
... work for you with code built from the cvs tip? I did an update and
build tonight and see
myst$ postmaster -i
postgres: invalid option -- r
Usage: postgres -boot [-d] [-D datadir] [-F] [-o file] [-x num] dbname -d debug mode -D datadir
datadirectory -F turn off fsync -o file send debug output to file -x num internal use
DEBUG: startup process 6818 exited with status 1; aborting startup
whereas omitting the "-i" seems to work better:
myst$ postmaster
DEBUG: database system was shut down at 2001-10-19 06:13:38 UTC
DEBUG: checkpoint record is at 0/112F54
DEBUG: redo record is at 0/112F54; undo record is at 0/0; shutdown TRUE
DEBUG: next transaction id: 89; next oid: 16556
DEBUG: database system is ready
I didn't see this symptom this morning afaict. Any ideas??
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
> ... work for you with code built from the cvs tip? I did an update and
> build tonight and see
> myst$ postmaster -i
> postgres: invalid option -- r
Hmm. I was fooling with postmaster.c & postgres.c last night.
I didn't think I touched parameter parsing --- and my test setup
does use -i --- but I'll take another look :-(
regards, tom lane
> ... work for you with code built from the cvs tip? I did an update and
> build tonight and see
A bit more information: an unadorned "-i" fails:
myst$ postmaster -i
postgres: invalid option -- r
Usage: postgres -boot [-d] [-D datadir] [-F] [-o file] [-x num] dbname -d debug mode -D datadir
datadirectory -F turn off fsync -o file send debug output to file -x num internal use
DEBUG: startup process 7172 exited with status 1; aborting startup
But no arguments succeeds:
myst$ postmaster
DEBUG: database system was shut down at 2001-10-19 13:38:20 UTC
DEBUG: checkpoint record is at 0/1191A4
DEBUG: redo record is at 0/1191A4; undo record is at 0/0; shutdown TRUE
DEBUG: next transaction id: 98; next oid: 16557
DEBUG: database system is ready
DEBUG: fast shutdown request
DEBUG: shutting down
DEBUG: database system is shut down
And multiple arguments succeeds (without damaging the other arguments):
myst$ postmaster -i -p 12000
DEBUG: database system was shut down at 2001-10-19 13:39:08 UTC
DEBUG: checkpoint record is at 0/1191E4
DEBUG: redo record is at 0/1191E4; undo record is at 0/0; shutdown TRUE
DEBUG: next transaction id: 98; next oid: 16557
DEBUG: database system is ready
DEBUG: fast shutdown request
DEBUG: shutting down
DEBUG: database system is shut down
I've done a "make clean all install", and did not see this symptom
earlier (I've been building and running quite often the last few days
with updated cvs sources).
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
> ... work for you with code built from the cvs tip? I did an update and
> build tonight and see
> myst$ postmaster -i
> postgres: invalid option -- r
I just rebuilt from cvs tip, and I don't see any such problem...
anyone else?
regards, tom lane
> We do "optind = 1"
> in SSDataBase, but maybe on your platform, we need to do more than that
> to point getopt at the correct arglist. Any ideas?
Ah ... I betcha your platform needs optreset = 1. Fix coming ...
regards, tom lane
Thomas Lockhart <lockhart@fourpalms.org> writes:
> A bit more information: an unadorned "-i" fails:
> myst$ postmaster -i
> postgres: invalid option -- r
> But no arguments succeeds:
> myst$ postmaster
> And multiple arguments succeeds (without damaging the other arguments):
> myst$ postmaster -i -p 12000
All three of these cases work just fine for me. Maybe some platform
dependency has snuck in? Hard to see how though. It looks like the
failure is occurring when the postmaster launches the xlog startup
subprocess. The building of the argument list for that subprocess is
fixed and not dependent on what you give to the postmaster (see
SSDataBase in postmaster.c).
Hmm... I wonder if the argument list itself is good, and the parsing is
what's broken. We're using getopt() for that, and there's an ugliness
in that getopt has static state that has to be reset (since it's already
been used once to parse the postmaster's arglist). We do "optind = 1"
in SSDataBase, but maybe on your platform, we need to do more than that
to point getopt at the correct arglist. Any ideas?
regards, tom lane
...
> All three of these cases work just fine for me. Maybe some platform
> dependency has snuck in? Hard to see how though. It looks like the
> failure is occurring when the postmaster launches the xlog startup
> subprocess. The building of the argument list for that subprocess is
> fixed and not dependent on what you give to the postmaster (see
> SSDataBase in postmaster.c).
No ideas at all; this stuff has always worked for me (and everyone
else). Let's wait and see if anyone else notices a problem; in the
meantime I have a workaround by giving it more than one argument per one
of the examples.
I *haven't* blown away my tree and done a build from scratch, but istm
that is not something that would magically get things working.
Hmm. I'll try a distclean and see if that helps; maybe configure has
changed a bit and the cache is messing me up??
- Thomas
> Ah ... I betcha your platform needs optreset = 1. Fix coming ...
I've just committed this. Please update and let me know if it helps.
regards, tom lane
Thomas Lockhart <lockhart@fourpalms.org> writes:
> A bit more information: an unadorned "-i" fails:
I believe this is fixed now.
regards, tom lane
> > A bit more information: an unadorned "-i" fails:
> I believe this is fixed now.
Seems to be, on my Linux box. Thanks for tracking it down...
- Thomas