Thread: 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.