| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, joerg(at)netbsd(dot)org |
| Subject: | Re: DROP DATABASE doesn't force other backends to close FDs |
| Date: | 2020-03-29 23:22:03 |
| Message-ID: | 20200329232203.7dfzcivkdqf36iet@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-10-03 15:37:25 -0700, Andres Freund wrote:
> Joerg reported on IRC that after a DROP DATABASE the space of the
> dropped database wasn't available to the OS until he killed a session
> that was active from before the drop. I was kinda incredulous at first,
> the code looks sane... Thomas figured out significant parts of this.
> [ context ]
> That unfortunately disregards that normal backends could have plenty
> files open for the to-be-dropped database, if there's any sort of
> shared_buffer pressure. Whenever a backend writes out a dirty victim
> page belonging to another database, it'll also open files therein.
Ping? As far as I can tell this is still an issue. And I think the
issue exists not just or entire databases, but also tables.
I think is likely relevant for complaints like
https://www.postgresql.org/message-id/20200329224913.GA11265%40hjp.at
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-03-30 00:25:32 | Re: snapper vs. HEAD |
| Previous Message | Andres Freund | 2020-03-29 23:17:08 | Re: snapper vs. HEAD |