Re: walsender performance regression due to logical decoding on standby changes
От | Amit Kapila |
---|---|
Тема | Re: walsender performance regression due to logical decoding on standby changes |
Дата | |
Msg-id | CAA4eK1LTcqyaSBdACRM+QyZtDO6zd-40NoqMoxRbW4TQ5yAtUA@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: walsender performance regression due to logical decoding on standby changes ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: walsender performance regression due to logical decoding on standby changes
|
Список | pgsql-hackers |
On Wed, May 10, 2023 at 3:41 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > On Wednesday, May 10, 2023 2:36 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > > > > > > My current guess is that mis-using a condition variable is the best bet. I > > > think it should work to use ConditionVariablePrepareToSleep() before a > > > WalSndWait(), and then ConditionVariableCancelSleep(). I.e. to never use > > > ConditionVariableSleep(). The latch set from ConditionVariableBroadcast() > > > would still cause the necessary wakeup. > > > > How about something like the attached? Recovery and subscription tests > > don't complain with the patch. > > Thanks for the patch. I noticed one place where the logic is different from before and > just to confirm: > > if (AllowCascadeReplication()) > - WalSndWakeup(switchedTLI, true); > + ConditionVariableBroadcast(&WalSndCtl->cv); > > After the change, we wakeup physical walsender regardless of switchedTLI flag. > Is this intentional ? if so, I think It would be better to update the comments above this. > This raises the question of whether we need this condition variable logic for physical walsenders? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: