Re: BUG #14830: Missed NOTIFications, PostgreSQL 9.1.24

Tom Lane wrote:
> Marko Tiikkaja <marko(at)joh(dot)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