Date: Tue, 10 Oct 2017 16:06:21 +0200
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>
Subject: Re: BUG #14830: Missed NOTIFications, PostgreSQL 9.1.24
Message-ID: <20171010140621.u4avva4cxylwpyew@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <15645.1507643938@sss.pgh.pa.us>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

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


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs