Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY

On Sat, Feb 24, 2024 at 04:16:24PM +0530, Robert Haas wrote:
> On Sat, Feb 24, 2024 at 10:05 AM Noah Misch <noah@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.