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 1mtZJu-0001H2-VR for pgsql-performance@arkaria.postgresql.org; Sat, 04 Dec 2021 17:59:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mtZJt-0001H8-TA for pgsql-performance@arkaria.postgresql.org; Sat, 04 Dec 2021 17:59:33 +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 1mtZJt-0001Gz-EP for pgsql-performance@lists.postgresql.org; Sat, 04 Dec 2021 17:59:33 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mtZJq-0006Lb-Cj for pgsql-performance@postgresql.org; Sat, 04 Dec 2021 17:59:33 +0000 Received: by mail-io1-xd34.google.com with SMTP id p23so7894151iod.7 for ; Sat, 04 Dec 2021 09:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=o6ikxqhzhrkVhhITBUTzimx6RAv9Lk7e9uclyu5tWZU=; b=K+dNBAwj6MxEmjtVmXylWmStqUGlR7Zau7UKvkHLcTmurWyAtBUPnEJuLTr9zr708E fKLM1YEZOM4bTe+Mhw42VsJXSAk2/FKxchyqijIlw+A/ls1G7gJ4vem1msRtdEkiD5c3 XiCHbO/nskWdmG/7yHuUbvtxEyRAR2SJa9ryvENb7cZeznJ0d7e9uFt0fIYNdchDrkL1 4TW5+KzbrB1qaNevungE6DvdmNDU7pGm8dLtatKXxGleX4S149+QFiKQnnnC5ufoRlBU qYkIHBwdNeyOLITdEpnVAA5VErZsWo1f5TMRrcRlps7iruGJh9+1dTr+1TzJw1fjeYXD g9hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=o6ikxqhzhrkVhhITBUTzimx6RAv9Lk7e9uclyu5tWZU=; b=XxF5b0enCmFv3EmfIUi7SR5eUdSzN5ReOwgZzn7b5qqk8QdTp9kPiKOXW82jh7sj9P Mx6Kj6daIq93Us9GYY9wm02udrwd/Fro17f4cbHKodIgUjstMP8iU8AvmF1olnB0OUJc eRwB26JqMZaOkjIiiGyrqm3kAsa3AXRtKBfyDLq/83b1lXRajCynn8T5HsHLjqRX+tDC 4DBw5mstJ3D+Rc6J8bk164Tk9SiLXLD9N2GFVp+MVlrJjktuAc70Jxt/s/fauMlAcnUi CAoN0s6mvpVYIDTZHeRXuFNgvY6iEi07uaK9HRQOYdJ0mH1w2x6IBTxc92q1g5eYXWNv SX7g== X-Gm-Message-State: AOAM531hoCCTMysIRO92WfgSAiBmhvhvSshRH1Xa6BciwV8YvxxGBeXa bzkqv+7/LoIuqTGSuYVXOUiDp1YgWf+3Rg== X-Google-Smtp-Source: ABdhPJxIcUnWoa6cCyDw+gELWKjYwO3mpiyjjBaEsHpvQtNGdAwwecmQwSkgabaC35s7tbbSiMoJTQ== X-Received: by 2002:a05:6638:dc3:: with SMTP id m3mr32542765jaj.106.1638640767567; Sat, 04 Dec 2021 09:59:27 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id p14sm3679937iod.38.2021.12.04.09.59.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Dec 2021 09:59:27 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id C7B258009D6; Sat, 4 Dec 2021 11:59:26 -0600 (CST) Date: Sat, 4 Dec 2021 11:59:26 -0600 From: Justin Pryzby To: ldh@laurent-hasson.com Cc: pgsql-performance@postgresql.org Subject: Re: An I/O error occurred while sending to the backend (PG 13.4) Message-ID: <20211204175926.GC17618@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Dec 04, 2021 at 05:32:10PM +0000, ldh@laurent-hasson.com wrote: > I have a data warehouse with a fairly complex ETL process that has been running for years now across PG 9.6, 11.2 and now 13.4 for the past couple of months. I have been getting the error "An I/O error occurred while sending to the backend" quite often under load in 13.4 which I never used to get on 11.2. I have applied some tricks, particularly with the socketTimeout JDBC configuration. > > So my first question is whether anyone has any idea why this is happening? My hardware and general PG configuration have not changed between 11.2 and 13.4 and I NEVER experienced this on 11.2 in about 2y of production. > > Second, I have one stored procedure that takes a very long time to run (40mn more or less), so obviously, I'd need to set socketTimeout to something like 1h in order to call it and not timeout. That doesn't seem reasonable? Is the DB server local or remote (TCP/IP) to the client? Could you collect the corresponding postgres query logs when this happens ? It'd be nice to see a network trace for this too. Using tcpdump or wireshark. Preferably from the client side. FWIW, I suspect the JDBC socketTimeout is a bad workaround. -- Justin