Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk7AO-0004kf-V7 for pgsql-performance@arkaria.postgresql.org; Thu, 28 Apr 2022 16:38:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nk7AN-000356-8v for pgsql-performance@arkaria.postgresql.org; Thu, 28 Apr 2022 16:38:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk7AM-00034u-VK for pgsql-performance@lists.postgresql.org; Thu, 28 Apr 2022 16:38:54 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk7AK-00033x-V2 for pgsql-performance@lists.postgresql.org; Thu, 28 Apr 2022 16:38:54 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 23SGcZAM021910; Thu, 28 Apr 2022 12:38:36 -0400 From: Tom Lane To: "Peter Eser HEUFT [Germany]" cc: pgsql-performance@lists.postgresql.org Subject: Re: LISTEN NOTIFY sometimes huge delay In-reply-to: References: Comments: In-reply-to "Peter Eser HEUFT [Germany]" message dated "Thu, 28 Apr 2022 16:28:15 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21908.1651163915.1@sss.pgh.pa.us> Date: Thu, 28 Apr 2022 12:38:35 -0400 Message-ID: <21909.1651163915@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Peter Eser HEUFT [Germany]" writes: > I have a table with time series data and on this table a trigger for > notifies: > containers_notify AFTER INSERT ON containers FOR EACH ROW EXECUTE > PROCEDURE containers_notify('containers_notify_collector') > and the function does: > PERFORM pg_notify(CAST(TG_ARGV[0] AS text), row_to_json(NEW)::text); > This works as a charm but occasionally (I think with more load on the > system) the notifications are received much time (up to hours!) after > the INSERTs. > Nevertheless no notifications become lost, they are only very late! The > delay grows, seems as a queue grows, but the java process tries to fetch > the notifications fairly fast, Hm. We've not previously had reports of late notifications. One idea that comes to mind is that the server won't deliver notifications as long as the client has an open transaction, so is it possible your listening process sometimes forgets to close its transaction? > Versions: > PostgreSQL 10.12 on x86_64-pc-linux-gnu, compiled by > x86_64-pc-linux-gnu-gcc (Gentoo 6.4.0-r1 p1.3) 6.4.0, 64-bit > JDBC 42.2.23 That's pretty old. We've made a number of changes to the LISTEN/NOTIFY code since then; although in reading the commit log entries about them, nothing is said about long-delayed notifications. regards, tom lane