From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, richard(dot)klaumann(at)gmail(dot)com |
Subject: | Re: BUG #16012: vacuum full, something weird |
Date: | 2019-09-18 20:31:05 |
Message-ID: | CAMkU=1xFE4Fez7=ZqurLYBNts85yQVAh8pR+68cOCgWuME+4qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Sep 18, 2019 at 9:25 AM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 16012
> Logged by: Richard Klaumann
> Email address: richard(dot)klaumann(at)gmail(dot)com
> PostgreSQL version: 9.5.3
> Operating system: Centos 7.x
> Description:
>
> Hello,
> First sorry for my english.
> Today we store our byteas in tables. We are moving these files to
> storages.
> During the process we set the bytea column to null and execute vacum full
> (in the table itself and in the table pg_catalog.pg_largeobject).
>
pg_largeobject has nothing to do with data stored in bytea columns.
> In some tables we continue with pg_total_relation_size> 24GB (practically
> the initial size). Data in the toast table.
> If I run a new vacuum full on the main table, the space is freed.
>
Data can only be freed once every snapshot that could possibly be
interested in it has closed.
So if you have any long-running statements, or long-open transactions with
isolation level above read-committed, it would inhibit the removal of the
data by vacuum full (or any other level of vacuum)
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Morris de Oryx | 2019-09-19 00:32:08 | citext LIKE search bug |
Previous Message | PG Bug reporting form | 2019-09-18 16:49:43 | BUG #16013: Unexpected results from bit field query |