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

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

In response to

Browse pgsql-general by date

  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