On Mon, Feb 11, 2019 at 10:21 AM Tom Lane wrote:
> Ah, so Andrew was correct: we panicked due to lack of WAL space, and
> that explains why the vacuuming process didn't have an opportunity
> to delete the files belonging to the uncommitted new relation.
> It's a pretty well-understood dynamic, I
Hannes Erven writes:
> Am 10.02.19 um 16:41 schrieb Tom Lane:
>> What do you mean by "crash" exactly?
> Here's the exact log (the pgadmin process was running the VACCUM FULL):
> 2019-02-09 23:44:53.516 CET [20341] @/ <> PANIC: could not write to
> file "pg_wal/xlogtemp.20341": No space left on
Hi again,
Am 10.02.19 um 16:41 schrieb Tom Lane:
Hannes Erven writes:
I've just had a "VACUUM FULL " crash due to 100% disk usage.
Clearly my fault, I was expecting the new table to be small enough.
What do you mean by "crash" exactly? A normal transactional failure
should've cleaned up or
> "Tom" == Tom Lane writes:
> Hannes Erven writes:
>> I've just had a "VACUUM FULL " crash due to 100% disk usage.
>> Clearly my fault, I was expecting the new table to be small enough.
Tom> What do you mean by "crash" exactly? A normal transactional
Tom> failure should've cleaned up o
Hannes Erven writes:
> I've just had a "VACUUM FULL " crash due to 100% disk usage.
> Clearly my fault, I was expecting the new table to be small enough.
What do you mean by "crash" exactly? A normal transactional failure
should've cleaned up orphaned files. I suppose if the kernel decided to
k
Hi,
I've just had a "VACUUM FULL " crash due to 100% disk usage.
Clearly my fault, I was expecting the new table to be small enough.
After freeing up space, restarting the cluster and issuing another
VACCUM FULL, I noticed that the cluster was way bigger that it should be.
In the base// folder
