On 2020-Apr-08, Thomas Munro wrote:
> Rationalize GetWalRcv{Write,Flush}RecPtr().
>
> GetWalRcvWriteRecPtr() previously reported the latest *flushed*
> location. Adopt the conventional terminology used elsewhere in the tree
> by renaming it to GetWalRcvFlushRecPtr(), and likewise for some related
> variables that used the term "received".
>
> Add a new definition of GetWalRcvWriteRecPtr(), which returns the latest
> *written* value. This will allow later patches to use the value for
> non-data-integrity purposes, without having to wait for the flush
> pointer to advance.
It seems worth pointing out that the new GetWalRcvWriteRecPtr function
has a different signature from the original one -- so any third-party
code using the original function will now get a compile failure that
should alert them that they need to change their code to call
GetWalRcvFlushRecPtr instead. Maybe we should add a line or two in the
comments GetWalRcvWriteRecPtr to make this explicit.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services