| From: | Murali Natti <murali(dot)natti(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16427: pgsql_tmp - temp files not released |
| Date: | 2020-07-13 22:44:41 |
| Message-ID: | CAE2yBfK4pXk0cY9vG5rJQv9qAoOBYPOs0uCp=iSP7+uVN281sw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
It again happened today and this time it happened in PG11.4 DB. We had to
bounce the instance to clear the space.
On Sun, May 10, 2020 at 11:10 PM Michael Paquier <michael(at)paquier(dot)xyz>
wrote:
> On Sun, May 10, 2020 at 10:48:58AM -0300, Euler Taveira wrote:
> > I wonder if a GUC (cleanup_temp_files_after_crash) is useful for an
> > environment that has storage restrictions. This is the second time this
> > month that I stumbled on this issue. Of course, I don't expect a postgres
> > crash once a while but we know that, due to extensibility, some
> extensions
> > could crash and the only workaround to this issue is to restart service
> > (which means a human intervention and an additional downtime).
>
> Sounds like a fair concern to me. It is annoying to have to do some
> manual intervention for some environments under disk pressure.
> --
> Michael
>
--
Thanks,
Murali
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2020-07-14 00:06:25 | Re: BUG #16526: pg_test_fsync in v12 doesn't run in Windows |
| Previous Message | Tom Lane | 2020-07-13 22:11:19 | Re: BUG #16536: Segfault with partition-wise joins |