From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
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-06 00:38:32 |
Message-ID: | 20201106003832.GD21123@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Nov 05, 2020 at 10:21:40AM +0100, Magnus Hagander wrote:
> 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.
This one is a bit new to me. I certainly saw my share of stat() or
open() calls failing on ENOPERM because of file handles taken
exclusively by external scanners around here or even with
customer-related issues, and I did not expect that such dark magic
could be involved in a write. It would indeed not be surprising to
see a PANIC depending on what gets done.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-11-06 01:10:28 | Re: PANIC: could not write to log file {} at offset {}, length {}: Invalid argument |
Previous Message | Adrian Klaver | 2020-11-05 21:34:43 | Re: pgagent |