On Sat, Feb 24, 2024 at 04:16:24PM +0530, Robert Haas wrote: > On Sat, Feb 24, 2024 at 10:05 AM Noah Misch <n...@leadboat.com> wrote: > > On Fri, Feb 23, 2024 at 08:47:52PM +0530, Robert Haas wrote: > > > I thought about whether there were any other WAL records that have > > > similar problems to XLOG_DBASE_CREATE_FILE_COPY and didn't come up > > > with anything. If anyone knows of any similar cases, please let me > > > know. > > > > 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.
Agreed, those don't touch relation data files. I think you've got all relation data file mutations. XLOG_DBASE_CREATE_FILE_COPY and XLOG_DBASE_DROP are the only record types that touch a relation data file without mentioning it in XLogRecordBlockHeader, XACT_XINFO_HAS_RELFILELOCATORS, or an RM_SMGR_ID rlocator field. > > 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. No relevance, given incremental backup is incremental with respect to relation data blocks only.
