Re: XID-wraparound hazards in LISTEN/NOTIFY - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: XID-wraparound hazards in LISTEN/NOTIFY
Date
Msg-id ZUvYfbM2RaJ8d4uN@momjian.us
Whole thread Raw
In response to Re: XID-wraparound hazards in LISTEN/NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: XID-wraparound hazards in LISTEN/NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Nov 23, 2019 at 12:10:56PM -0500, Tom Lane wrote:
> Mark Dilger <hornschnorter@gmail.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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Syncrep and improving latency due to WAL throttling
Next
From: Alexander Lakhin
Date:
Subject: Re: Fix some memory leaks in ecpg.addons