Re: pg_stat_wal_receiver and flushedUpto/writtenUpto
От | Fujii Masao |
---|---|
Тема | Re: pg_stat_wal_receiver and flushedUpto/writtenUpto |
Дата | |
Msg-id | c049ffcf-d2fe-90f7-c8ba-0741035aa6a7@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: pg_stat_wal_receiver and flushedUpto/writtenUpto (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_stat_wal_receiver and flushedUpto/writtenUpto
|
Список | pgsql-hackers |
On 2020/05/17 10:08, Michael Paquier wrote: > On Sat, May 16, 2020 at 10:15:47AM +0900, Michael Paquier wrote: >> Thanks. If there are no objections, I'll revisit that tomorrow and >> apply it with those changes, just in time for beta1. > > Okay, done this part then. 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 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. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: