Re: PANIC: could not write to log file {} at offset {}, length {}: Invalid argument

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>, Shani Israeli <sisraeli(at)illusivenetworks(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: PANIC: could not write to log file {} at offset {}, length {}: Invalid argument
Date: 2020-11-05 09:21:40
Message-ID: CABUevEzXHYcyVe2Ew25dVDwLzy=fnKKz6i+_Z9Cz=MLaMUPH8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Nov 5, 2020 at 3:12 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Nov 04, 2020 at 01:24:46PM +0100, Andreas Kretschmer wrote:
> >> Any ideas about what is the problem? or anything else I need to check?
> >
> > wild guess: Antivirus Software?
>
> Perhaps not. To bring more context in here, PostgreSQL opens any
> files on WIN32 with shared writes and reads allowed to have an
> equivalent of what we do on all *nix platforms. Note here that the
> problem comes from a WAL segment write, which is done after the file
> handle is opened in shared mode. As long as the fd is correctly
> opened, any attempt for an antivirus software to open a file with an
> exclusive write would be blocked, no?

The problem with AVs generally doesn't come from them opening files in
non-share mode (I've, surprisingly enough, seen backup software that
causes that problem for example). It might happen on scheduled scans
for example, but the bigger problem with AV software has always been
their filter driver software which intercepts both the open/close and
the read/write calls an application makes and "does it's magic" on
them before handing the actual call up to the operating system. It's
completely independent of how the file is opened.

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lu, Chenyang 2020-11-05 13:26:38 ssl certification
Previous Message Simon Riggs 2020-11-05 08:45:17 Re: Christopher Browne