Re: standby apply lag on inactive servers
От | Fujii Masao |
---|---|
Тема | Re: standby apply lag on inactive servers |
Дата | |
Msg-id | dc8616a6-f2eb-f1d5-f373-ae042cd61b19@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: standby apply lag on inactive servers (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: standby apply lag on inactive servers
|
Список | pgsql-hackers |
On 2020/01/31 22:40, Alvaro Herrera wrote: > On 2020-Jan-31, Fujii Masao wrote: > >> You're thinking to apply this change to the back branches? Sorry >> if my understanding is not right. But I don't think that back-patch >> is ok because it changes the documented existing behavior >> of pg_last_xact_replay_timestamp(). So it looks like the behavior >> change not a bug fix. > > Yeah, I am thinking in backpatching it. The documented behavior is > already not what the code does. Maybe you thought this because getRecordTimestamp() extracts the timestamp from even WAL record of a restore point? That is, you're concerned about that pg_last_xact_replay_timestamp() returns the timestamp of not only commit/abort record but also restore point one. Right? As far as I read the code, this problem doesn't occur because SetLatestXTime() is called only for commit/abort records, in recoveryStopsAfter(). No? > Do you have a situation where this > change would break something? If so, can you please explain what it is? For example, use the return value of pg_last_xact_replay_timestamp() (and also the timestamp in the log message output at the end of recovery) as a HINT when setting recovery_target_time later. Use it to compare with the timestamp retrieved from the master server, in order to monitor the replication delay. Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
В списке pgsql-hackers по дате отправления: