From: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
---|---|
To: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com> |
Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |
Date: | 2025-08-19 17:37:54 |
Message-ID: | CAJDiXgjQZgHLFziG6sS6D5CGYqohMio673ydiRkkffW3WfXmEg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Tue, Aug 19, 2025 at 6:31 PM Matheus Alcantara
<matheusssilv97(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-08-19 17:38:49 | Re: Reduce "Var IS [NOT] NULL" quals during constant folding |
Previous Message | Tom Lane | 2025-08-19 17:37:01 | Re: Performance issue on temporary relations |