Re: [HACKERS] pg_resetxlog options
Some other time maybe. Meanwhile, this patch ought to make it compile more cleanly on Windows - not sure why I get errors there but not Linux. Because getopt() is normally declared in unistd.h, not getopt.h (Windows being an exception?). getopt is not in any standard Windows headers. The getopt.h header is from mingw to assist porting (don't know why they didn't put it in unistd.h ?). Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_resetxlog options
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Why does pg_resetxlog seem top be the only one of our programs that has no long form options (or at least the only one that calls getopt rather than getopt_long)? Should we make it consistent with everything else? I think just laziness on my part when I first wrote it --- it only had one or two options anyway, and didn't seem to need long options. But if converting to getopt_long is the easy way to avoid a porting problem, do it. Some other time maybe. Meanwhile, this patch ought to make it compile more cleanly on Windows - not sure why I get errors there but not Linux. cheers andrew Index: src/bin/pg_resetxlog/pg_resetxlog.c === RCS file: /home/cvsmirror/pgsql/src/bin/pg_resetxlog/pg_resetxlog.c,v retrieving revision 1.24 diff -c -r1.24 pg_resetxlog.c *** src/bin/pg_resetxlog/pg_resetxlog.c 29 Aug 2004 16:34:48 - 1.24 --- src/bin/pg_resetxlog/pg_resetxlog.c 17 Nov 2004 20:24:43 - *** *** 36,41 --- 36,45 #include sys/time.h #include time.h #include unistd.h + #ifdef HAVE_GETOPT_H + #include getopt.h + #endif + #include access/xlog.h #include access/xlog_internal.h ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_resetxlog options
Andrew Dunstan [EMAIL PROTECTED] writes: Some other time maybe. Meanwhile, this patch ought to make it compile more cleanly on Windows - not sure why I get errors there but not Linux. The Single Unix Spec says that getopt() is supposed to be defined by unistd.h, but I guess reading the spec closely is not a hobby in Redmond... Patch applied. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_resetxlog options
Andrew Dunstan wrote: Some other time maybe. Meanwhile, this patch ought to make it compile more cleanly on Windows - not sure why I get errors there but not Linux. Because getopt() is normally declared in unistd.h, not getopt.h (Windows being an exception?). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_resetxlog options
Andrew Dunstan [EMAIL PROTECTED] writes: Why does pg_resetxlog seem top be the only one of our programs that has no long form options (or at least the only one that calls getopt rather than getopt_long)? Should we make it consistent with everything else? I think just laziness on my part when I first wrote it --- it only had one or two options anyway, and didn't seem to need long options. But if converting to getopt_long is the easy way to avoid a porting problem, do it. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_resetxlog options
Peter Eisentraut wrote: pg_resetxlog uses a non-standard options parsing method: The -l option requires two arguments (-l fileid seg). I propose to change this to -l fileid,seg which is the standard way to separate suboptions. Agreed. Secondly, the -n option appears to be redundant with pg_controldata. Do we need it? Yep. Thirdly, pg_resetxlog uses the term guessed controldata values if it can't read the real ones. I found this to be confusing, because the code doesn't do a whole lot of guessing. Would it be better to say that the values are simply defaulted (and to what)? Attempts to determine the proper values? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_resetxlog options
Peter Eisentraut [EMAIL PROTECTED] writes: pg_resetxlog uses a non-standard options parsing method: The -l option requires two arguments (-l fileid seg). I propose to change this to -l fileid,seg which is the standard way to separate suboptions. No objection. I think pg_upgrade uses that option, so please adjust it too. Secondly, the -n option appears to be redundant with pg_controldata. Do we need it? I would like to keep it. It gives some comfort factor that pg_resetxlog has chosen the right things to do, before it does them. Thirdly, pg_resetxlog uses the term guessed controldata values if it can't read the real ones. I found this to be confusing, because the code doesn't do a whole lot of guessing. There needs to be more AI in there than there presently is ;-), but I think the term is quite appropriate. Without a readable pg_control, pg_resetxlog really is guessing at a number of critical data items, such as the next transaction ID, the locale, etc. I *want* the user to be apprehensive if that flow of control is taken, and I think a term like guessed will induce an appropriately paranoid frame of mind. If you'd like to propose alternate wording, feel free, but default is not it. If I read we used the default values, I'm going to think everything is fine and no thought is required. That's exactly the wrong thing for a user of pg_resetxlog to think. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
