Обсуждение: Re: pgsql: Rationalize GetWalRcv{Write,Flush}RecPtr().

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

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 their code to call
> GetWalRcvFlushRecPtr instead.  Maybe we should add a line or two in the
> comments GetWalRcvWriteRecPtr to make this explicit.

After using codesearch.debian.net and finding no results, I decided that
this is not worth the effort.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, Apr 16, 2020 at 9:24 AM Alvaro Herrera <alvherre@2ndquadrant.com> 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 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.
>
> After using codesearch.debian.net and finding no results, I decided that
> this is not worth the effort.

Thanks for checking.  Yeah, it looks like you're right.
codesearch.debian.net is cool.