From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | reiner peterke <zedaardv(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PANIC: could not flush dirty data: Operation not permitted power8, Redhat Centos |
Date: | 2019-08-18 19:32:25 |
Message-ID: | CA+hUKG+VDnzZzuX72RoTV3R1E7AHhGmHWFcAJnhirP75vwA3FQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 17, 2019 at 1:04 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Mon, Apr 15, 2019 at 7:57 PM <zedaardv(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2019-08-18 19:35:33 | Re: Zedstore - compressed in-core columnar storage |
Previous Message | Tom Lane | 2019-08-18 18:59:53 | Re: Rethinking opclass member checks and dependency strength |