On Thu, Apr 16, 2020 at 9:24 AM Alvaro Herrera wrote:
> On 2020-Apr-09, Alvaro Herrera wrote:
> > 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 com
On 2020-Apr-09, Alvaro Herrera wrote:
> 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
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 relate
