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 1nk58A-00044s-4n for pgsql-performance@arkaria.postgresql.org; Thu, 28 Apr 2022 14:28:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nk588-0007z9-T0 for pgsql-performance@arkaria.postgresql.org; Thu, 28 Apr 2022 14:28:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk588-0007yz-IU for pgsql-performance@lists.postgresql.org; Thu, 28 Apr 2022 14:28:28 +0000 Received: from mx02.heuft.org ([80.149.45.6]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk585-0006E1-HZ for pgsql-performance@lists.postgresql.org; Thu, 28 Apr 2022 14:28:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=heuft.com; s=mx01-dkim1909; h=Content-Transfer-Encoding:Content-Type:Subject:To:From: MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=BTCzhpkPR+s1ab7s+HVc/ZNN7y3vOQrby3pRjD3saaU=; b=Uohs/TjL7Bozg2P2vq6Nsi/RxG O3mmniP5JwqegtLurpGliVeGPJBnJyqVJ4wbg/A3xsg7Eeu/Ya7WDPfQ2InififOmy/7aJV4br/Qe lnuO0Ye3IJnF1jgKNtEBLDPwNtslsWuPmxD5QrrsN+JQ+zzARR+GjOCednP41ybNxXxs=; Received: from [172.20.1.52] (port=35231 helo=mail-smtp03.heuft.org) by mx02.heuft.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nk57x-0005Ek-4V for pgsql-performance@lists.postgresql.org; Thu, 28 Apr 2022 16:28:17 +0200 Received: (qmail 31566 invoked by uid 0); 28 Apr 2022 14:28:16 -0000 Received: from unknown (HELO [172.17.5.29]) (pes@[172.17.5.29]) (envelope-sender ) by 172.20.1.52 (qmail-ldap-1.03) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 28 Apr 2022 14:28:16 -0000 Message-ID: Date: Thu, 28 Apr 2022 16:28:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-GB From: "Peter Eser HEUFT [Germany]" To: pgsql-performance@lists.postgresql.org Subject: LISTEN NOTIFY sometimes huge delay Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-HEUFT-ARCHIVE: outgoing X-HEUFT-PROCESS: mail-smtp03.heuft.org List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi all, 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); so that another application (java) fetches every inserted row as a JSON for further processing every half second: ...listenStatement.execute("LISTEN 'containers_notify_collector'"); ...PGNotification notifications[] = ((org.postgresql.PGConnection)notifyPGCon.getUnderlyingConnection()).getNotifications(); 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, so there should be no queue growing.. 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 The commit of the application inserting the data is ok/fast. So the insert of the data is not slowed down. Are the notifications delivered asynchronously to the commit/trigger? Thanks for any help, Peter