Re: BUG #16012: vacuum full, something weird

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

In response to

Browse pgsql-bugs by date

  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