Re: DROP DATABASE doesn't force other backends to close FDs

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: DROP DATABASE doesn't force other backends to close FDs
Дата
Msg-id 20200329232203.7dfzcivkdqf36iet@alap3.anarazel.de
обсуждение исходный текст
Ответ на DROP DATABASE doesn't force other backends to close FDs  (Andres Freund <andres@anarazel.de>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: snapper vs. HEAD
Следующее
От: Tom Lane
Дата:
Сообщение: Re: snapper vs. HEAD