From: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why does PostgreSQL ftruncate before unlink? |
Date: | 2014-02-24 17:38:01 |
Message-ID: | CAKuK5J0ajFMyWSnDGRDdnLSfY7M2vQ2zqRKVHrRscoJe=dEyog@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Feb 23, 2014 at 10:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> writes:
>> On Sun, Feb 23, 2014 at 9:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2014-02-24 18:33:25 | Re: Why does PostgreSQL ftruncate before unlink? |
Previous Message | Magnus Hagander | 2014-02-24 15:27:06 | Re: stand by is starting until I do some work in the primary |