Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY
От | Robert Haas |
---|---|
Тема | Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY |
Дата | |
Msg-id | CA+TgmoZTD9qu_ihK+TXOUHz9ejj9Ati_4xu0cALfv_k7t1AsBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY
|
Список | pgsql-hackers |
On Sat, Feb 24, 2024 at 10:05 AM Noah Misch <noah@leadboat.com> wrote: > Regarding records the summarizer potentially can't ignore that don't deal in > relfilenodes, these come to mind: > > XLOG_DBASE_DROP - covered in this thread's patch > XLOG_RELMAP_UPDATE > XLOG_TBLSPC_CREATE > XLOG_TBLSPC_DROP > XLOG_XACT_PREPARE At present, only relation data files are ever sent incrementally; I don't think any of these touch those. > Also, any record that writes XIDs needs to update nextXid; likewise for other > ID spaces. See the comment at "XLOG stuff" in heap_lock_tuple(). Perhaps you > don't summarize past a checkpoint, making that irrelevant. I'm not quite following this. It's true that we summarize from one redo pointer to the next; but also, our summary is only trying to ascertain which relation data blocks have been modified. Therefore, I don't understand the relevance of nextXid here. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: