Re: Why does PostgreSQL ftruncate before unlink? - Mailing list pgsql-general

From Jon Nelson
Subject Re: Why does PostgreSQL ftruncate before unlink?
Date
Msg-id CAKuK5J0ajFMyWSnDGRDdnLSfY7M2vQ2zqRKVHrRscoJe=dEyog@mail.gmail.com
Whole thread Raw
In response to Re: Why does PostgreSQL ftruncate before unlink?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why does PostgreSQL ftruncate before unlink?  (Francisco Olarte <folarte@peoplecall.com>)
List pgsql-general
On Sun, Feb 23, 2014 at 10:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jon Nelson <jnelson+pgsql@jamponi.net> writes:
>> On Sun, Feb 23, 2014 at 9:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> If memory serves, the inode should get removed during the next checkpoint.
>
>> I was moments away from commenting to say that I had traced the flow
>> of the code to md.c and found the comments there quite illuminating. I
>> wonder if there is a different way to solve the underlying issue
>> without relying on ftruncate (which seems to be somewhat expensive).
>
> Hm.  The code is designed the way it is on the assumption that ftruncate
> doesn't do anything that unlink wouldn't have to do anyway.  If it really
> is significantly slower on popular filesystems, maybe we need to revisit
> that.
>

Here is an example.

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.95    3.207681        4182       767           ftruncate
  0.05    0.001579           1      2428      2301 unlink

--
Jon


pgsql-general by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: stand by is starting until I do some work in the primary
Next
From: Francisco Olarte
Date:
Subject: Re: Why does PostgreSQL ftruncate before unlink?