Re: Race condition in InvalidateObsoleteReplicationSlots()
От | vignesh C |
---|---|
Тема | Re: Race condition in InvalidateObsoleteReplicationSlots() |
Дата | |
Msg-id | CALDaNm3ugGkQ-AGisPzMTKcHYwkX6_yWS77PA29hXCdBKGP3oQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Race condition in InvalidateObsoleteReplicationSlots() (Álvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Race condition in InvalidateObsoleteReplicationSlots()
|
Список | pgsql-hackers |
On Wed, Jun 23, 2021 at 7:32 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2021-Jun-20, Tom Lane wrote: > > > Actually ... isn't there a second race, in the opposite direction? > > IIUC, the point of this is that once we force some WAL to be sent > > to the frozen sender/receiver, they'll be killed for failure to > > respond. But the advance_wal call is not the only possible cause > > of that; a background autovacuum for example could emit some WAL. > > So I fear it's possible for the 'to release replication slot' > > message to come out before we capture $logstart. I think you > > need to capture that value before the kill not after. > > I accounted for all those things and pushed again. I saw that this patch is pushed. If there is no pending work left for this, can we change the commitfest entry to Committed. Regards, Vignesh
В списке pgsql-hackers по дате отправления: