From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Thomas Munro <tmunro(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Rationalize GetWalRcv{Write,Flush}RecPtr(). |
Date: | 2020-04-09 21:49:47 |
Message-ID: | 20200409214947.GA22655@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-04-10 02:26:45 | pgsql: Fix collection of typos and grammar mistakes in the tree |
Previous Message | Tom Lane | 2020-04-09 21:31:59 | Re: pgsql: Remove testing for precise LSN/reserved bytes in new TAP test |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-04-09 21:57:02 | Re: [Patch] Use internal pthreads reimplementation only when building with MSVC |
Previous Message | Robert Haas | 2020-04-09 20:56:03 | Re: Catalog invalidations vs catalog scans vs ScanPgRelation() |