From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, pgsql <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why does PostgreSQL ftruncate before unlink? |
Date: | 2014-02-24 03:49:57 |
Message-ID: | 4716.1393213797@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Sunday, February 23, 2014, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
>> I'm guessing that this is so that it can be rolled back. Unlink is
>> likely issued at commit;
> I would hope that ftruncate is issued at commit as well. That doesn't
> sound undoable.
It's more subtle than that. I'm too lazy to look at the comments in md.c
right now, but basically the reason for not doing an instant unlink is
to ensure that if a relation is truncated and then re-extended, open file
pointers held by other backends will still be valid. The ftruncate is
done to ensure that allocated disk space goes away as soon as that's safe
(ie, at commit of the truncation); but immediate unlink would require
forcing more cross-backend synchronization than we want to have.
If memory serves, the inode should get removed during the next checkpoint.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Nelson | 2014-02-24 04:00:09 | Re: Why does PostgreSQL ftruncate before unlink? |
Previous Message | Jeff Janes | 2014-02-24 03:36:42 | Re: Why does PostgreSQL ftruncate before unlink? |