From: | Chris Travers <chris(dot)travers(at)adjust(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Orphaned files in base/[oid] |
Date: | 2017-08-15 06:24:37 |
Message-ID: | CAN-RpxBNY5ra19Z2YLQ=v3wA17Tmed9f9_=yaXBAua_CxsGkhg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
There's another side to this and that I am not sure it is a backend crash.
Here is what I did to reproduce:
2 virtual disk images: 100mb for main data, 40 MB for WAL. work_mem set
to 256MB. The idea is to test different out of space conditions.
Create table as ...; drop table; select
pg_size_pretty(pg_current_xlog_location() - '0/0');
I played around with parameters to determine how different kinds of out of
space errors were handled.
1. running out of temp space was cleaned up without a server restart
needed.
2. A relation running out of disk space *seemed* to get cleaned up.
3. Running out of WAL space left *both* temp and non-temp files.
I wonder about a different solution. Would it be possible to special case
vacuum to check for and remove (or just move to where they can be removed)
files when vacuuming pg_class? At the point we are vacuuming pg_class, we
ought to be able to know that a relfilenode shouldn't be used anymore,
right?
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-08-15 06:53:48 | Re: Pluggable storage |
Previous Message | Thomas Munro | 2017-08-15 05:44:55 | Re: POC: Sharing record typmods between backends |