Re: Why copy_relation_data only use wal whenWALarchivingis enabled
В списке pgsql-hackers по дате отправления:
| От | Florian G. Pflug |
|---|---|
| Тема | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Дата | |
| Msg-id | 47176B73.1030007@phlo.org обсуждение исходный текст |
| Ответ на | Re: Why copy_relation_data only use wal whenWALarchivingis enabled (Heikki Linnakangas <heikki@enterprisedb.com>) |
| Список | pgsql-hackers |
Heikki Linnakangas wrote: > Tom Lane wrote: >> I tend to agree that truncating the file, and extending the fsync >> request mechanism to actually delete it after the next checkpoint, >> is the most reasonable route to a fix. > > Ok, I'll write a patch to do that. What is the argument against making relfilenodes globally unique by adding the xid and epoch of the creating transaction to the filename? Those 64 bits could be stuffed into 13 bytes by base-36 encoding (A-Z,0-9). The maximum length of a relfilenode would then be 10 + 1 + 13 = 24, which any reasonable filesystem should support IMHO. regards, Florian Pflug PS: Sorry if this arrives twice - I'm having a few troubles with my mail setup.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера