From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
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
In-reply-to: <20171010140621.u4avva4cxylwpyew@alvherre.pgsql>
References: <20171010140621.u4avva4cxylwpyew@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Tue, 10 Oct 2017 16:06:21 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16670.1507645188.1@sss.pgh.pa.us>
Date: Tue, 10 Oct 2017 10:19:48 -0400
Message-ID: <16671.1507645188@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> 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.

Sure, but if they're truly idle, they aren't looking at RecentXmin ;-)

> Would they not recompute RecentXmin if they did a
> sinval reset?

Not sure, but if not, maybe making that code path update it would be
a suitable fix in practice?  I'm a bit hesitant to put a GetSnapshotData
call into ProcessIncomingNotify, because of the possibility of adding a
lot of contention on the ProcArray if there's very heavy notify traffic.

			regards, tom lane


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