Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
| От | Neha Khatri |
|---|---|
| Тема | Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn() |
| Дата | |
| Msg-id | CAFO0U+9dcCTqvYptmpJ2QpJ-5zvzJJwNjY=_fdP+S42Kq67_5Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn() (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
|
| Список | 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 по дате отправления: