Recently, on my PostgreSQL logs, I found :

2021-09-30 08:33:37.242 CEST [4183904] PANIC: could not write to file "pg_wal/xlogtemp.4183904": No space left on device 2021-09-30 08:33:37.242 CEST [4183904] CONTEXT: writing block 413931 of relation base/238033/270693 2021-09-30 08:33:46.609 CEST [1376] LOG: server process (PID 4183904) was terminated by signal 6: Aborted 2021-09-30 08:33:46.609 CEST [1376] DETAIL: Failed process was running: autovacuum: VACUUM public.public_components_versions_files

My question is why the process autovacuum cause writing block of relation (index on table), knowing that autovacuum not reclaim space.... for information base/238033/270693 is an index for table public_components_versions_files, so autovacuum (public_components_versions_files) attempt to writing block for index (index on public_components_versions_files)

postrgesqL version 12.8

<I see on documentation : The standard form of VACUUM removes dead row versions in tables and indexes and marks the space available for future reuse. However, it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained>

So perhaps, this autovacuum return the space to the operating system, because one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained

Thank you in advance.

Cheers,

Adil

CodePudding user response：

VACUUM writes to the table (it modifies it), but it does not extend the table. However, since all data modifications have to be logged in the Write Ahead Log, VACUUM's modifications have to be logged as well.

PostgreSQL is running out of space writing the transaction log, not modifying the table.