Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQYXN-00BDG6-1v for pgsql-general@arkaria.postgresql.org; Tue, 02 Dec 2025 22:07:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQYXM-00AByb-2L for pgsql-general@arkaria.postgresql.org; Tue, 02 Dec 2025 22:07:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQYXM-00AByS-1I for pgsql-general@lists.postgresql.org; Tue, 02 Dec 2025 22:07:56 +0000 Received: from mail-ot1-x32b.google.com ([2607:f8b0:4864:20::32b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vQYXK-002oJJ-20 for pgsql-general@lists.postgresql.org; Tue, 02 Dec 2025 22:07:56 +0000 Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-7c6ce4f65f7so4323235a34.0 for ; Tue, 02 Dec 2025 14:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764713272; x=1765318072; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=MnbdK+jbnICJcaHcap7QsKGat7lam0d5GPCIdFdez9s=; b=ZE2SIPF3BCJhnE3N77v0jOb3sHs5ZOVJRp0EWh8K92NzdWetHglRTNlX2QT//CmO0n Mu7cwMFR+JsxC/m69ZetnPIfjmY6S3HSzV+lvQvpcVT9stjyjy3TcC3GkmdlzyceFAVx L8bp915B1V0XDq9l5JKLGf+9HCcSsJTLIA+3GJ1tCMfksuxaRwh7o/UvU5VBTra/YjoO 3MlwRPB30pejT6ej3OiaUhKgQ2NGR58PFjdQXW/6tj72oWoNYCdlb7PHX83LXSLy+yev +Qtrk2wUliM/3Mv3SPa/J2T7IsIlraKVmJ3A3gYRcaP5W82JRkYzozCy48OPPVdI3IMx NpsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764713272; x=1765318072; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MnbdK+jbnICJcaHcap7QsKGat7lam0d5GPCIdFdez9s=; b=iZjsEbGb0/d0cro+DANM0E4g/FEkmg6s7Y1TvSqfR3f53S7PxW3V1eEmFGcv1PMa8x 4JKBCwxkWhRRIWQ1CtG/mrwK3K+5wt0wpU06DLAmsZ0R+QGwWVWuG23pXFo6WRr89S/p o4BLPASR9iuB8nin9WWqv4kbCr+NiIqtzuzpUhO8FKr0/gn6xFc3idxEBKD6ez43BCku VNboPOo9oS1ZwHr9U2PeE4oW0Cgux2oZq2yR5NpX2rCtuOauarGpCfoWUxiNRxxN52pP Qn6sPfS+6PTpmBYmq0yHBzQr7xh7128uEUlrn2bkt4PsZ1bw+tDD3N6z1zrR9xM6y6uN gB0Q== X-Gm-Message-State: AOJu0Yw09g1uGln1gQ1bo20usEOVDTkW2pPNTypm0uJ36GEe07/f3TOP ZEiizlZGwC93f9EKlDn0rUe2wZvZKQckejdfd36K/VL42rh/s4sv86OC9m1kTqp9UhlAa943FEr ZmhN2pJsLy7qK981gqX8TzZ934d56KQBLWg== X-Gm-Gg: ASbGncuc1U5/aLqXr8oytz9F2C9S5FDFjlAF+BSHVF42SYPuK76TxF/WWyE5kZs9fYO di2+jRjIMNtQk7QJ5VsRSXMKR+ccQFY9c6HMjFAunZUO2wd3Zi9YrfzR+2Kw88s0W0PrV5uoCGI 9H6fEZaKtDIA6a+GiPz0sY0TZeNaa/F23NakwzWX//CUBSqggrG+LjCMyUMI/MkSVHbvHQWhOLe d2I8o4Huf8eP/gBOP+S7nqACfr9oWliFM5yuY7EyGNvZZfh1lJs91Cx+GNQFJ+9ebpwpSeU X-Google-Smtp-Source: AGHT+IGQBBvDxIHQskyRcDfvblLk61nRx+Hi+Zfyfw/l/aplTbdeUdaiCzhP3XnmTnij+phuAozM7yv6NahSLXxKzBw= X-Received: by 2002:a05:6830:917:b0:7b7:59c5:766c with SMTP id 46e09a7af769-7c94db64483mr132591a34.33.1764713272373; Tue, 02 Dec 2025 14:07:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Tue, 2 Dec 2025 17:07:41 -0500 X-Gm-Features: AWmQ_bnl1nl5FGECu65eEL67Vwok_h0XOuB4rZgGZk3ftxd4kS7GG32oBh3N5KM Message-ID: Subject: Re: wdavdaemon / Microsoft Defender for Endpoint on Linux and slow Postgres recovery? To: PostgreSQL General Content-Type: multipart/alternative; boundary="000000000000baf5a00644ff53d5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000baf5a00644ff53d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 2, 2025 at 3:35=E2=80=AFPM Christoph Moench-Tegeder wrote: > ## Colin 't Hart (colinthart@gmail.com): > > > I wonder if anyone here has any experience with configuring exclusions = so > > that the WAL files can be processed faster? > > https://learn.microsoft.com/en-us/defender-endpoint/linux-exclusions > mind this: > > https://learn.microsoft.com/en-us/defender-endpoint/linux-exclusions#supp= orted-exclusion-scopes > and work from these examples (if you're allowed to): > > https://learn.microsoft.com/en-us/defender-endpoint/linux-exclusions#exam= ple-3-add-or-remove-a-folder-exclusion > > > Any advice on what to communicate with their IT department about using > this > > on their database servers? I've never encountered it on Linux before... > > "Be glad it only slows your database down. All too often, AV/Endpoint > Protection Products just don't like the access pattern and eat your > database for breakfast." There is this joke "it has been 0 days since > Anti-Virus ate a database". > Things must have improved, since we had Carbon Black for a number of years, and now use Coretex XDR. CB would quite often consume 300% CPU, while XDR "only" uses 100% on occasion, but have never corrupted or crashed a PG instance. (This is standard installations, with no exclusions.) --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000baf5a00644ff53d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 2, 2025 at 3:35=E2=80=AFPM Ch= ristoph Moench-Tegeder <cmt@burggr= aben.net> wrote:
## Colin 't Hart (= colinthart@gmail.= com):

> I wonder if anyone here has any experience with configuring exclusions= so
> that the WAL files can be processed faster?

https://learn.microsoft.com/en-u= s/defender-endpoint/linux-exclusions
mind this:
https= ://learn.microsoft.com/en-us/defender-endpoint/linux-exclusions#supported-e= xclusion-scopes
and work from these examples (if you're allowed to):
https://learn.microsoft.com/en-us/defender-endpoint/linux-exclu= sions#example-3-add-or-remove-a-folder-exclusion

> Any advice on what to communicate with their IT department about using= this
> on their database servers? I've never encountered it on Linux befo= re...

"Be glad it only slows your database down. All too often, AV/Endpoint<= br> Protection Products just don't like the access pattern and eat your
database for breakfast." There is this joke "it has been 0 days s= ince
Anti-Virus ate a database".
=C2=A0
Thin= gs must have improved, since we had Carbon Black for a number of years, and= now use Coretex XDR.

CB would quite often consume= 300% CPU, while XDR "only" uses 100% on occasion, but have never= corrupted or crashed a PG instance.=C2=A0 (This is standard installations,= with no exclusions.)

--
Death to <Redacted>, and butter sauce.
Don't boil = me, I'm still alive.
<Redacted> lobster!
=
--000000000000baf5a00644ff53d5--