On 2020/05/20 8:31, Michael Paquier wrote:
On Tue, May 19, 2020 at 11:38:52PM +0900, Fujii Masao wrote:
I found that "received_lsn" is still used in high-availability.sgml.
We should apply the following change in high-availability?
- view's <literal>received_lsn</literal> indicates that WAL is being
+ view's <literal>flushed_lsn</literal> indicates that WAL is being
Oops, thanks. Will fix.
Thanks for the fix!
BTW, we have pg_last_wal_receive_lsn() that returns the same lsn as
pg_stat_wal_receiver.flushed_lsn. Previously both used the term "receive"
in their names, but currently not. IMO it's better to use the same term in
those names for the consistency, but it's not good idea to rename
pg_last_wal_receive_lsn() to something like pg_last_wal_receive_lsn().
I have no better idea for now. So I'm ok with the current names.
I think you mean renaming pg_last_wal_receive_lsn() to something like
pg_last_wal_flushed_lsn(), no?
No, that's not good idea, as I told upthread.
This name may become confusing because
we lose the "receive" idea in the function, that we have with the
"receiver" part of pg_stat_wal_receiver. Maybe something like that,
though that's long:
- pg_last_wal_receive_flushed_lsn()
- pg_last_wal_receive_written_lsn()
Yes, that's long.
Anyway, a rename of this function does not strike me as strongly
necessary, as that's less tied with the shared memory structure, and
we document that pg_last_wal_receive_lsn() tracks the current LSN
received and flushed. I am actually wondering if in the future it may
not be better to remove this function, but it has no maintenance
cost either so I would just let it as-is.
Yeah, agreed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
