Re: Fetching timeline during recovery

On Fri, 26 Jul 2019 18:22:25 +0200
Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote:

> 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()

I just found I forgot to use PG_RETURN_INT32 in pg_last_wal_received_tl().
Please find the corrected patch in attachment:
0001-v3-Add-functions-to-get-timeline.patch

Also, TimeLineID is declared as a uint32. So why do we use
PG_RETURN_INT32/Int32GetDatum to return a timeline and not PG_RETURN_UINT32?
See eg. in pg_stat_get_wal_receiver().

Regards,