Re: BUG #14830: Missed NOTIFications, PostgreSQL 9.1.24
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marko Tiikkaja <marko@joh.to>
Cc: Michael Paquier <michael.paquier@gmail.com>,
PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-10-09T15:15:10Z
Lists: pgsql-bugs
Marko Tiikkaja <marko@joh.to> writes: > After running it for a few days I start getting logged messages such as: > out of order notification Q_97882353: 97882353 != 97882349 + 1 (prefix Q) > out of order notification F_97947433: 97947433 != 97947429 + 1 (prefix F) > out of order notification F_97947439: 97947439 != 97947436 + 1 (prefix F) > I did it on both 9.1.24 and 9.6.5 and they both exhibit the same behavior: > it takes days to get into this state, but then notifications are missed all > the time. I currently have both systems in this state, so any idea what to > look at to try and debug this further? You might try gdb'ing the recipient and stepping through asyncQueueProcessPageEntries to see what happens. Are the missing entries present in the queue but it decides to ignore them for some reason, or are they just not there? An interesting black-box test might be to do this with two receiver processes and see if they miss identical sets of messages. That would be a different way of triangulating on question number 1, which is whether the sender or the recipient is at fault. I wonder whether the long ramp-up time indicates that you have to wrap around some counter somewhere before things go south. Although the only obvious candidate is wrapping the pg_notify SLRU queue, and I'd think that would have happened many times already. regards, tom lane
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