Re: Why copy_relation_data only use wal whenWALarchivingis enabled
В списке pgsql-hackers по дате отправления:
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Дата | |
| Msg-id | 47176A64.60108@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Why copy_relation_data only use wal whenWALarchivingis enabled (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Tom Lane wrote: > Heikki Linnakangas <heikki@enterprisedb.com> writes: >> The best I can think of is to rename the obsolete file to >> <relfilenode>.stale, when it's scheduled for deletion at next >> checkpoint, and check for .stale-suffixed files in GetNewRelFileNode, >> and delete them immediately in DropTableSpace. > > This is getting too Rube Goldbergian for my tastes. What if we just > make DROP TABLESPACE force a checkpoint before proceeding? True, that would work. DROP TABLESPACE should be uncommon enough that the performance hit is ok. We only need to checkpoint if the directory isn't empty, though I think that's the case more often than not; you're most likely to drop a tablespace right after dropping all relations in it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера