Re: Implement waiting for wal lsn replay: reloaded
| От | Xuneng Zhou |
|---|---|
| Тема | Re: Implement waiting for wal lsn replay: reloaded |
| Дата | |
| Msg-id | CABPTF7X0n=R50z2fBpj3EbYYz04Ab0-DHJa+JfoAEny62QmUdg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Implement waiting for wal lsn replay: reloaded (Xuneng Zhou <xunengzhou@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Jan 9, 2026 at 9:44 PM Xuneng Zhou <xunengzhou@gmail.com> wrote: > > Hi, > > On Fri, Jan 9, 2026 at 4:42 AM Alexander Korotkov <aekorotkov@gmail.com> wrote: > > > > On Thu, Jan 8, 2026 at 6:29 PM Xuneng Zhou <xunengzhou@gmail.com> wrote: > > > On Thu, Jan 8, 2026 at 10:19 PM Alexander Korotkov <aekorotkov@gmail.com> wrote: > > > > I see, you were right. This is not related to the MyProc->xmin. > > > > ResolveRecoveryConflictWithTablespace() calls > > > > GetConflictingVirtualXIDs(InvalidTransactionId, InvalidOid). That > > > > would kill WAIT FOR LSN query independently on its xmin. > > > > > > I think the concern is valid --- conflicts like > > > PROCSIG_RECOVERY_CONFLICT_SNAPSHOT could occur and terminate the > > > backend if the timing is unlucky. It's more difficult to reproduce > > > though. A check for the log containing "conflict with recovery" would > > > likely catch these conflicts as well. > > > > Yes, I found multiple reasons why xmin gets temporarily set during > > processing of WAIT FOR LSN query. I'll soon post a draft patch to fix > > that. > > > > > > I guess your > > > > patch is the only way to go. It's clumsy to wrap WAIT FOR LSN call > > > > with retry loop, but it would still consume less resources than > > > > polling. > > > > > > > > > > Assuming recovery conflicts are relatively rare in tap tests, except > > > for the explicitly designed tests like 031_recovery_conflict and the > > > narrow timing window that the standby has not caught up while the wait > > > for gets invoked, a simple fallback seems appropriate to me. > > > > Yes, I see. Seems acceptable given this seems the only feasible way to go. > > > > Here is the updated patch with recovery conflicts handled. V2 corrected the commit message to state " if the WAIT FOR LSN session is interrupted by a recovery conflict (e.g., DROP TABLESPACE triggering conflicts on all backends),". In this case, the statement is canceled when possible; in some states (idle in transaction or subtransaction) the session may be terminated. -- Best, Xuneng
Вложения
В списке pgsql-hackers по дате отправления: