From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Dilger <hornschnorter(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: XID-wraparound hazards in LISTEN/NOTIFY |
Date: | 2023-11-08 18:50:37 |
Message-ID: | ZUvYfbM2RaJ8d4uN@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 23, 2019 at 12:10:56PM -0500, Tom Lane wrote:
> Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
> > On 11/23/19 8:34 AM, Tom Lane wrote:
> >> It suddenly strikes me to worry that we have an XID wraparound hazard
> >> for entries in the notify queue.
>
> > Is it worth checking for this condition in autovacuum?
>
> Dunno, maybe. It's a different avenue to consider, at least.
>
> > There shouldn't be too much reason to back-patch any of this, since
> > the change in 51004c717 only applies to v13 and onward. Or do you
> > see the risk you described as "pretty minimal" as still being large
> > enough to outweigh the risk of anything we might back-patch?
>
> There may not be a risk large enough to worry about before 51004c717,
> assuming that we discount cases like a single session staying
> idle-in-transaction for long enough for the XID counter to wrap
> (which'd cause problems for more than just LISTEN/NOTIFY). I haven't
> analyzed this carefully enough to be sure. We'd have to consider
> that, as well as the complexity of whatever fix we choose for HEAD,
> while deciding if we need a back-patch.
Is this still an open issue? Should it be a TODO item?
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2023-11-08 19:00:00 | Re: Fix some memory leaks in ecpg.addons |
Previous Message | Tomas Vondra | 2023-11-08 18:29:38 | Re: Syncrep and improving latency due to WAL throttling |