| От | Tom Lane |
|---|---|
| Тема | Re: [PATCHES] WAL logging freezing |
| Дата | |
| Msg-id | 29109.1162307200@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [PATCHES] WAL logging freezing (Heikki Linnakangas <heikki@enterprisedb.com>) |
| Список | pgsql-hackers |
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> I got another idea. If we make sure that vacuum removes any aborted xid
> older than OldestXmin from the table, we can safely assume that any xid
> < the current clog truncation point we are going to be interested in is
> committed. Vacuum already removes any tuple with an aborted xmin. If we
> also set any aborted xmax (and xvac) to InvalidXid, and WAL logged that,
The problem with that is all the extra WAL log volume it creates. I'm
also concerned about the loss of forensic information --- xmax values
are frequently useful for inferring what's been going on in a database.
(This is another reason for not wanting a very short freeze interval BTW.)
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера