Re: PANIC: could not flush dirty data: Operation not permittedpower8, Redhat Centos - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: PANIC: could not flush dirty data: Operation not permittedpower8, Redhat Centos
Date
Msg-id CA+hUKG+VDnzZzuX72RoTV3R1E7AHhGmHWFcAJnhirP75vwA3FQ@mail.gmail.com
Whole thread Raw
In response to Re: PANIC: could not flush dirty data: Operation not permittedpower8, Redhat Centos  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: PANIC: could not flush dirty data: Operation not permittedpower8, Redhat Centos
List pgsql-hackers
On Wed, Apr 17, 2019 at 1:04 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Mon, Apr 15, 2019 at 7:57 PM <zedaardv@gmail.com> wrote:
> > I forgot to mention that this is happening in a docker container.
>
> Huh, so there may be some configuration of Linux container that can
> fail here with EPERM, even though that error that does not appear in
> the man page, and doesn't make much intuitive sense.  Would be good to
> figure out how that happens.

Steve Dodd ran into the same problem in Borg[1].  It looks like what's
happening here is that on PowerPC and ARM systems, there is a second
system call sync_file_range2 that has the arguments arranged in a
better order for their calling conventions (see Notes section of man
sync_file_range), and glibc helpfully translates for you, but some
container technologies forgot to include sync_file_range2 in their
syscall forwarding table.  Perhaps we should just handle this with the
not_implemented_by_kernel mechanism I added for WSL.

[1] https://lists.freedesktop.org/archives/systemd-devel/2019-August/043276.html

-- 
Thomas Munro
https://enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rethinking opclass member checks and dependency strength
Next
From: Justin Pryzby
Date:
Subject: Re: Zedstore - compressed in-core columnar storage