From: | Haozhou Wang <hawang(at)pivotal(dot)io> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Vacuum Full does not release the disk size space after delete from table |
Date: | 2018-11-05 03:24:33 |
Message-ID: | CAL_NLpJGJP0hyu=aUeyk=7VAsvcGLVdqs4QAEA2AWcnpTgHf8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thank Tom!
We will check it.
On Fri, Nov 2, 2018 at 10:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Haozhou Wang <hawang(at)pivotal(dot)io> writes:
> > We meet a corner case that related to the behavior of Vacuum Full.
> > ...
> > If we run both sql scripts on same database in parallel, the "VACUUM FULL
> > a;" will not release the disk space.
>
> I think what's happening is that the delete in script 1 happens after the
> "pg_sleep" in script 2 starts. Then the pg_sleep has an open snapshot
> that could potentially see the deleted rows, so they can't be removed yet.
>
> You could check this theory by changing the vacuum to use VERBOSE, and
> seeing what it says about rows that can't be removed yet.
>
> regards, tom lane
>
--
Regards,
Haozhou
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-11-05 04:37:51 | Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT |
Previous Message | Amit Kapila | 2018-11-05 03:00:15 | Re: zheap: a new storage format for PostgreSQL |