From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14830: Missed NOTIFications, PostgreSQL 9.1.24 |
Date: | 2017-10-10 14:06:21 |
Message-ID: | 20171010140621.u4avva4cxylwpyew@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2017-10-10 14:09:29 | Re: BUG #14830: Missed NOTIFications, PostgreSQL 9.1.24 |
Previous Message | Tom Lane | 2017-10-10 13:58:58 | Re: BUG #14830: Missed NOTIFications, PostgreSQL 9.1.24 |