Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Date
Msg-id 20487.1494514594@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Neha Khatri <nehakhatri5@gmail.com>)
Responses Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Neha Khatri <nehakhatri5@gmail.com>)
List pgsql-hackers
Neha Khatri <nehakhatri5@gmail.com> writes:
> [In case forgotten] pg_controdata and pg_waldump interfaces should also be
> considered for this standardization.

> Following are pg_controldata interfaces that might require change:

>   Latest checkpoint location:
>   Prior checkpoint location:
>   Latest checkpoint's REDO location:
>   Minimum recovery ending location:
>   Backup start location:
>   Backup end location:

My inclination is to leave these messages alone.  They're not really
inconsistent with anything.  Where we seem to be ending up is that
"lsn" will be used in things like function and column names, but
documentation will continue to spell out phrases like "WAL location".

There is another open thread about converting said phrases to be
more consistent --- a lot of them currently say "transaction log
location", which is not a very good choice because it invites
confusion with pg_xact nee pg_clog.  But I think that's mostly
just documentation changes, and in any case it's better done as
a separate patch.

> The pg_waldump help options(and probably documentation) would also require
> change:
>   -e, --end=RECPTR       stop reading at log position RECPTR
>   -s, --start=RECPTR     start reading at log position RECPTR

Yeah, probably s/log position/WAL location/ would be better here.
But again that seems like material for a separate patch.  The
current patch does do s/position/location/ in a few places, but
it's not trying to apply that policy everywhere.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] snapbuild woes