Re: Fetching timeline during recovery

Поиск
Список
Период
Сортировка
От Jehan-Guillaume de Rorthais
Тема Re: Fetching timeline during recovery
Дата
Msg-id 20190726182225.6dc23664@firost
обсуждение исходный текст
Ответ на Re: Fetching timeline during recovery  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Ответы Re: Fetching timeline during recovery  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Список pgsql-hackers
On Fri, 26 Jul 2019 10:02:58 +0200
Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote:

> On Fri, 26 Jul 2019 16:49:53 +0900 (Tokyo Standard Time)
> Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
[...]
> > We have an LSN reporting function each for several objectives.
> > 
> >  pg_current_wal_lsn
> >  pg_current_wal_insert_lsn
> >  pg_current_wal_flush_lsn
> >  pg_last_wal_receive_lsn
> >  pg_last_wal_replay_lsn  
> 
> Yes. In fact, my current implementation might be split as:
> 
>   pg_current_wal_tl: returns TL on a production cluster
>   pg_last_wal_received_tl: returns last received TL on a standby
> 
> If useful, I could add pg_last_wal_replayed_tl. I don't think *insert_tl and
> *flush_tl would be useful as a cluster in production is not supposed to
> change its timeline during its lifetime.
> 
> > But, I'm not sure just adding further pg_last_*_timeline() to
> > this list is a good thing..  
> 
> I think this is a much better idea than mixing different case (production and
> standby) in the same function as I did. Moreover, it's much more coherent with
> other existing functions.

Please, find in attachment a new version of the patch. It now creates two new
fonctions: 

  pg_current_wal_tl()
  pg_last_wal_received_tl()

Regards,

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ryan Lambert
Дата:
Сообщение: Re: Built-in connection pooler
Следующее
От: Amit Khandekar
Дата:
Сообщение: Re: POC: Cleaning up orphaned files using undo logs