Re: Why does PostgreSQL ftruncate before unlink?

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

In response to

Responses

Browse pgsql-general by date

  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?