Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
От | Daniil Davydov |
---|---|
Тема | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |
Дата | |
Msg-id | CAJDiXgjQZgHLFziG6sS6D5CGYqohMio673ydiRkkffW3WfXmEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue (Matheus Alcantara <matheusssilv97@gmail.com>) |
Ответы |
Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
|
Список | pgsql-hackers |
Hi, On Tue, Aug 19, 2025 at 6:31 PM Matheus Alcantara <matheusssilv97@gmail.com> wrote: > > On Tue Aug 19, 2025 at 12:57 AM -03, Daniil Davydov wrote: > > You have started a very long transaction, which holds its xid and prevents > > vacuum from freezing it. But what if the backend is stuck not inside a > > transaction? Maybe we can just hardcode a huge delay (not inside the > > transaction) or stop process execution via breakpoint in gdb. If we will use it > > instead of a long query, I think that this error may be reproducible. > > > But how could this happen in real scenarios? I mean, how the backend > could be stuck outside a transaction? > For now, I cannot come up with a situation where it may be possible. Perhaps, such a lagging may occur during network communication, but I couldn't reproduce it. Maybe other people know how we can achieve this? I think that if such a situation may be possible, the suggestion to delete messages will no longer be relevant. Therefore, first of all, I would like to clarify this issue. -- Best regards, Daniil Davydov
В списке pgsql-hackers по дате отправления: