From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Remove an unused function GetWalRcvWriteRecPtr |
Date: | 2022-03-26 17:52:44 |
Message-ID: | 88259.1648317164@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> writes:
> On Sat, Mar 26, 2022 at 10:57 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> -1. I think it's a perfectly reasonable function to have, it doesn't cause
>> architectural / maintenance issues to have it and there's several plausible
>> future uses for it (moving fsyncing of received WAL to different process,
>> optionally allowing logical decoding up to the written LSN, reporting function
>> for monitoring on the standby itself).
> Given the use-cases that it may have in future, I can use that
> function right now in pg_stat_get_wal_receiver instead of
> pg_atomic_read_u64(&WalRcv->writtenUpto);
I do not really see a reason to change anything at all here.
We have far better things to spend our (finite) time on.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-03-26 17:57:39 | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Previous Message | Tom Lane | 2022-03-26 17:51:07 | Re: Pointer subtraction with a null pointer |