From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Strange failure in LWLock on skink in REL9_5_STABLE |
Date: | 2018-09-21 04:36:06 |
Message-ID: | CAEepm=0Nuxv=th7NsUrPjea9UQq9mFyEKQ2oZoHMN1bGeHcT8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 21, 2018 at 4:06 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> > ... There may be ways to fix the dsm_resize() path
> > based on the observation that you don't need to fallocate() if you
> > made the mapping smaller, and if you made it bigger then you could
> > always undo that on error (or not) and you haven't thrown away any
> > data. Hmm... I note that there are actually no callers of
> > dsm_resize(), and it's not implemented on Windows or SystemV.
Erm, actually you probably only need to do ftruncate() *or*
posix_fallocate(), depending on the direction of the resize. Doing
both is redundant and introduces this theoretical hazard (in practice
I'd be surprised if fallocate() really can fail after you shrank a
file that was already fully allocated).
> Why would we fix it rather than just removing it?
I assumed we wouldn't remove an extern C function extension code
somewhere might use. Though admittedly I'd be surprised if anyone
used this one.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-21 04:42:01 | Re: Changing the setting of wal_sender_timeout per standby |
Previous Message | Andres Freund | 2018-09-21 04:20:05 | Re: Strange failure in LWLock on skink in REL9_5_STABLE |