From: | "ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)com> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | RE: An I/O error occurred while sending to the backend (PG 13.4) |
Date: | 2022-04-13 15:36:19 |
Message-ID: | MN2PR15MB2560C2027870AA2C1DECC29485EC9@MN2PR15MB2560.namprd15.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>From: Ranier Vilela ranier(dot)vf(at)gmail(dot)com<mailto:ranier(dot)vf(at)gmail(dot)com>
>Sent: Thursday, March 03, 2022 13:22
>
>
>You are welcome.
>
>regards,
>Ranier Vilela
Hello all,
After a lot of back and forth, someone in IT informed us that the database VM is under a backup schedule using Veeam. Apparently, during the backup window, Veeam creates a snapshot and that takes the VM offline for a couple of minutes… And of course, they scheduled this right at the busiest time of the day for this machine which is during our nightly ETL. Their backup doesn’t perform very week either, which explained why the failure seemed to randomly happen at various points during our ETL (which takes about 2h30mn).
They moved the schedule out and the issue has not happened again over the past 3 weeks. This looks like it was the root cause and would explain (I think) how the database and the client simultaneously reported a connection timeout.
Thank you so much for all your help in trying to figure this out and exonerate Postgres.
Thank you,
Laurent.
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-04-13 15:43:19 | Re: An I/O error occurred while sending to the backend (PG 13.4) |
Previous Message | andrew cooke | 2022-04-13 11:17:56 | Re: Performance for SQL queries on Azure PostgreSQL PaaS instance |