Re: Remove an unused function GetWalRcvWriteRecPtr - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Remove an unused function GetWalRcvWriteRecPtr
Date
Msg-id 20220326072525.rm3rihr2sig4i7gw@jrouhaud
Whole thread Raw
In response to Re: Remove an unused function GetWalRcvWriteRecPtr  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Remove an unused function GetWalRcvWriteRecPtr  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Re: Remove an unused function GetWalRcvWriteRecPtr  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Mar 26, 2022 at 02:52:29PM +0900, Michael Paquier wrote:
> On Sat, Mar 26, 2022 at 10:51:15AM +0530, Bharath Rupireddy wrote:
> > The function GetWalRcvWriteRecPtr isn't being used anywhere, however
> > pg_atomic_read_u64(&walrcv->writtenUpto); (reading writtenUpto without
> > spinlock) is being used directly in pg_stat_get_wal_receiver
> > walreceiver.c. We either make use of the function instead of
> > pg_atomic_read_u64(&walrcv->writtenUpto); or remove it. Since there's
> > only one function using walrcv->writtenUpto right now, I prefer to
> > remove the function to save some LOC (13).
> > 
> > Attaching patch. Thoughts?
> 
> This could be used by some external module, no?

Maybe, but WalRcv is exposed so if an external module needs it it could still
maintain its own version of GetWalRcvWriteRecPtr.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: Amit Kapila
Date:
Subject: Re: logical decoding and replication of sequences