From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | 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:36:42 |
Message-ID: | CAMkU=1zuk68Xp+yOiS-ZJUTCSabwnyBhE=iBgeTsDz14DQz7bw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sunday, February 23, 2014, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> On Fri, Feb 21, 2014 at 4:14 PM, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net<javascript:;>>
> wrote:
> > When dropping lots of tables, I noticed postgresql taking longer than
> > I would have expected.
> >
> > strace seems to report that the largest contributor is the ftruncate
> > and not the unlink. I'm curious what the logic is behind using
> > ftruncate before unlink.
> >
> > I'm using an ext4 filesystem.
>
> 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.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-24 03:49:57 | Re: Why does PostgreSQL ftruncate before unlink? |
Previous Message | Torsten Förtsch | 2014-02-24 03:23:16 | Re: How to continue streaming replication after this error? |