Re: BUG #14830: Missed NOTIFications, PostgreSQL 9.1.24
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Marko Tiikkaja <marko@joh.to>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-10-10T14:06:21Z
Lists: pgsql-bugs
Tom Lane wrote: > Marko Tiikkaja <marko@joh.to> writes: > > So I managed to accidentally kill and/or restart both servers while trying > > to install debug symbols, but I'm doing a new run now and I noticed > > something interesting: the listening backend's RecentXmin doesn't seem to > > ever go forward. By my reading of this code, that would mean trouble for > > this piece of code in TransactionIdIsInProgress: > > > if (TransactionIdPrecedes(xid, RecentXmin)) > > return false; > > Hmm ... I suppose it's possible that that happens if the listening > backend isn't executing any SQL commands but is just sitting. > While that might describe your test harness, does it describe any > real-world application? I think it's not totally unreasonable to have processes sitting idle for long periods of time. One example: a pooler configured to have more connections that are actually needed most of the time (I'm fairly sure I've seen this). Would they not recompute RecentXmin if they did a sinval reset? Also, a listener daemon for which notifications are very infrequent. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Fix low-probability loss of NOTIFY messages due to XID wraparound.
- 525b09adae78 9.2.24 landed
- f4cdf781a1d2 10.1 landed
- 7573d122f157 9.3.20 landed
- 69bc245d9296 9.5.10 landed
- 36c687a22f49 9.6.6 landed
- 118e99c3d71e 11.0 landed
- 0e84f70752cf 9.4.15 landed