Re: Assertion failure in SnapBuildInitialSnapshot()
От | Amit Kapila |
---|---|
Тема | Re: Assertion failure in SnapBuildInitialSnapshot() |
Дата | |
Msg-id | CAA4eK1LBJm48515uAoSqiD-qHxXQO9-nAVzps5U73abrrtdFVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertion failure in SnapBuildInitialSnapshot() (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
RE: Assertion failure in SnapBuildInitialSnapshot()
|
Список | pgsql-hackers |
On Thu, Dec 8, 2022 at 8:17 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > The same assertion failure has been reported on another thread[1]. > Since I could reproduce this issue several times in my environment > I've investigated the root cause. > > I think there is a race condition of updating > procArray->replication_slot_xmin by CreateInitDecodingContext() and > LogicalConfirmReceivedLocation(). > > What I observed in the test was that a walsender process called: > SnapBuildProcessRunningXacts() > LogicalIncreaseXminForSlot() > LogicalConfirmReceivedLocation() > ReplicationSlotsComputeRequiredXmin(false). > > In ReplicationSlotsComputeRequiredXmin() it acquired the > ReplicationSlotControlLock and got 0 as the minimum xmin since there > was no wal sender having effective_xmin. > What about the current walsender process which is processing running_xacts via SnapBuildProcessRunningXacts()? Isn't that walsender slot's effective_xmin have a non-zero value? If not, then why? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: