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 по дате отправления: