Re: Should pg_current_wal_location() become pg_current_wal_lsn()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neha Khatri <nehakhatri5(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should pg_current_wal_location() become pg_current_wal_lsn()
Date: 2017-05-11 14:56:34
Message-ID: 20487.1494514594@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neha Khatri <nehakhatri5(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-05-11 14:59:18 Re: snapbuild woes
Previous Message Tom Lane 2017-05-11 14:45:37 Re: Should pg_current_wal_location() become pg_current_wal_lsn()