Обсуждение: Which postgres process cleans up deprecated datafiles
Hi Team!
Teaching class a question has arisen.. about datafiles that remain after a truncate or vacuum full operation.
See a simple example before asking my question.
16470 is the filenode corresponding to the test table:
# select relname, relfilenode from pg_class where relname = 'test';
relname | relfilenode
---------+-------------
test | 16470
(1 row)
Exists in the filesystem:
$ ls -lh /postgresql/datos/base/12738/ | grep 16470
-rw------- 1 xxxxxxxxxxxxxx xxxxxxxxxxxxxx 50M mar 17 18:08 16470
I perform a truncate command on the table:
# truncate table test;
TRUNCATE TABLE
And the file still exists with size 0 bytes.
$ ls -lh /postgresql/datos/base/12738/ | grep 16470
-rw------- 1 xxxxxxxxxxxxxx xxxxxxxxxxxxxx 0 mar 17 18:20 16470
But a truncate command, PostgreSQL drops table and creates a new one. Now, filenode is 16476 and it also has 0 bytes.
# select relname, relfilenode from pg_class where relname = 'test';
relname | relfilenode
---------+-------------
test | 16476
(1 row)
$ ls -lh /postgresql/datos/base/12738/ | grep 16476
-rw------- 1 xxxxxxxxxxxxxx xxxxxxxxxxxxxx 0 mar 17 18:20 16476
Ok, but... after an indeterminate amount of time, the datafile 16470 disappeared.
Now the question.
What postgres process, or system, identify and delete datafiles that have become unassociated? The truncate operation doesn't appear to be.. the datafile has existed for some time after the truncate command execution finished.
Thanks and Greetings!
16470 is the filenode corresponding to the test table:
# select relname, relfilenode from pg_class where relname = 'test';
relname | relfilenode
---------+-------------
test | 16470
(1 row)
Exists in the filesystem:
$ ls -lh /postgresql/datos/base/12738/ | grep 16470
-rw------- 1 xxxxxxxxxxxxxx xxxxxxxxxxxxxx 50M mar 17 18:08 16470
I perform a truncate command on the table:
# truncate table test;
TRUNCATE TABLE
And the file still exists with size 0 bytes.
$ ls -lh /postgresql/datos/base/12738/ | grep 16470
-rw------- 1 xxxxxxxxxxxxxx xxxxxxxxxxxxxx 0 mar 17 18:20 16470
But a truncate command, PostgreSQL drops table and creates a new one. Now, filenode is 16476 and it also has 0 bytes.
# select relname, relfilenode from pg_class where relname = 'test';
relname | relfilenode
---------+-------------
test | 16476
(1 row)
$ ls -lh /postgresql/datos/base/12738/ | grep 16476
-rw------- 1 xxxxxxxxxxxxxx xxxxxxxxxxxxxx 0 mar 17 18:20 16476
Ok, but... after an indeterminate amount of time, the datafile 16470 disappeared.
Now the question.
What postgres process, or system, identify and delete datafiles that have become unassociated? The truncate operation doesn't appear to be.. the datafile has existed for some time after the truncate command execution finished.
Thanks and Greetings!
Loles <lolesft@gmail.com> writes: > What postgres process, or system, identify and delete datafiles that have > become unassociated? The truncate operation doesn't appear to be.. the > datafile has existed for some time after the truncate command execution > finished. The zero-length file is a placeholder to ensure that that relfilenode number doesn't get re-used right away. It'll get cleaned up during the next checkpoint. regards, tom lane