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

From Neha Khatri
Subject Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Date
Msg-id CAFO0U+9dcCTqvYptmpJ2QpJ-5zvzJJwNjY=_fdP+S42Kq67_5Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, May 6, 2017 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Noah Misch <noah@leadboat.com> writes:
> On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote:
>> Do any of the committers who voted for this change feel inclined to
>> pick this patch up?

> I'll echo that question.  This open item lacks a clear owner.  One might argue
> that 806091c caused it by doing the backward-compatibility breaks that
> inspired this patch, but that's a link too tenuous to create ownership.

If no one else takes this, I will pick it up --- but I don't anticipate
having any time for it until after Monday's back-branch release wraps.

[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:

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

Regards,
Neha

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal psql \gdesc
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER nameHANDLER ...