| От | Tom Lane |
|---|---|
| Тема | Re: It's past time to redo the smgr API |
| Дата | |
| Msg-id | 17804.1076024036@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: It's past time to redo the smgr API ("Marc G. Fournier" <scrappy@postgresql.org>) |
| Ответы |
Re: It's past time to redo the smgr API
|
| Список | pgsql-hackers |
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> k, but that would be a different scenario, no? As I mentioned in my
> original, a DROP TABLE would reset its timeout to -1, meaning to close it
> and drop it on the next checkpoint interval ...
How would it do that? These structs are local to particular backends,
so there's no way for a DROP TABLE occurring in one backend to reach
over and reset the timeout in the bgwriter process. If we add
communication that lets the bgwriter know the table is being dropped,
then the problem is solved directly.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера