Thread: pg_resetxlog options

pg_resetxlog options

From
Peter Eisentraut
Date:
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.

Secondly, the -n option appears to be redundant with pg_controldata.  Do
we need it?

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)?

-- 
Peter Eisentraut   peter_e@gmx.net



Re: pg_resetxlog options

From
Bruce Momjian
Date:
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 pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: pg_resetxlog options

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> 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