Re: Regardign RecentFlushPtr in WalSndWaitForWal()
От | Amit Kapila |
---|---|
Тема | Re: Regardign RecentFlushPtr in WalSndWaitForWal() |
Дата | |
Msg-id | CAA4eK1+LO+x6RREH434TGw4E_TK1UnrDK8nTL0xLQb4uFEdVMg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Regardign RecentFlushPtr in WalSndWaitForWal() (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: Regardign RecentFlushPtr in WalSndWaitForWal()
|
Список | pgsql-hackers |
On Fri, Mar 1, 2024 at 4:40 PM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > > On Mon, 26 Feb 2024 at 12:46, shveta malik <shveta.malik@gmail.com> wrote: > > > > Hi hackers, > > > > I would like to understand why we have code [1] that retrieves > > RecentFlushPtr in WalSndWaitForWal() outside of the loop. We utilize > > RecentFlushPtr later within the loop, but prior to that, we already > > have [2]. Wouldn't [2] alone be sufficient? > > > > Just to check the impact, I ran 'make check-world' after removing [1], > > and did not see any issue exposed by the test at-least. > > Yeah, that seems accurate. > > > Any thoughts? > [...] > > [2]: > > /* Update our idea of the currently flushed position. */ > > else if (!RecoveryInProgress()) > > I can't find where this "else" of this "else if" clause came from, as > this piece of code hasn't changed in years. > Right, I think the quoted code has check "if (!RecoveryInProgress())". > But apart from that, your > observation seems accurate, yes. > I also find the observation correct and the code has been like that since commit 5a991ef8 [1]. So, let's wait to see if Robert or Andres remembers the reason, otherwise, we should probably nuke this code. [1] commit 5a991ef8692ed0d170b44958a81a6bd70e90585c Author: Robert Haas <rhaas@postgresql.org> Date: Mon Mar 10 13:50:28 2014 -0400 Allow logical decoding via the walsender interface. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: