Re: fd.c: flush data problems on osx

From: Andres Freund <andres(at)anarazel(dot)de>
To: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fd.c: flush data problems on osx
Date: 2016-03-17 17:23:28
Message-ID: 20160317172328.uohb5bkwfszrlkqb@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2016-03-17 20:09:53 +0300, Stas Kelvich wrote:
> Current implementation of pg_flush_data when called with zero offset and zero nbytes is assumed to flush all file. In osx it uses mmap with these arguments, but according to man:
>
> "[EINVAL] The len argument was negative or zero. Historically, the system call would not return an
> error if the argument was zero. See other potential additional restrictions in the COMPAT-
> IBILITY section below."
>
> so it is generate a lot of warnings:
>
> "WARNING: could not mmap while flushing dirty data: Invalid argument"

Hm, yea, that's buggy.

> One possible solution for that is just fallback to pg_fdatasync in case when offset = nbytes = 0.

Hm, that's a bit heavyweight. I'd rather do an lseek(SEEK_END) to get
the file size. Could you test that?

> Also there are no default ifdef inside this function, is there any
> check that will guarantee that pg_flush_data will not end up with
> empty body on some platform?

There doesn't need to be - it's purely "advisory", i.e. just an
optimization.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-03-17 17:33:18 Re: Relaxing SSL key permission checks
Previous Message David Steele 2016-03-17 17:22:25 Re: Re: Add generate_series(date,date) and generate_series(date,date,integer)