On Thu, May 6, 2021 at 3:38 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Thu, May 6, 2021 at 8:27 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > > I'm doubtful about skipping WAL logging entirely - I'd have to think
> > > harder about it, but I think that'd mean we'd restart from scratch after
> > > crashes / immediate restarts as well, because we couldn't rely on the
> > > contents of the "dead tid" files to be accurate. In addition to the
> > > replication issues you mention.
> >
> > Yeah, not having WAL would have a big negative impact on other various
> > aspects. Can we piggyback the WAL for the TID fork and
> > XLOG_HEAP2_PRUNE? That is, we add the buffer for the TID fork to
> > XLOG_HEAP2_PRUNE and record one 64-bit number of the first dead TID in
> > the list so that we can add dead TIDs to the TID fork during replaying
> > XLOG_HEAP2_PRUNE.
>
> That could be an option but we need to be careful about the buffer
> lock order because now we will have to hold the lock on the TID fork
> buffer as well as the heap buffer so that we don't create any
> deadlock. And there is also a possibility of holding the lock on
> multiple TID fork buffers, which will depend upon how many tid we have
> pruned.
Not sure we will need to hold buffer locks for both the TID fork and
the heap at the same time but I agree that we could need to lock on
multiple TID fork buffers. We could need to add dead TIDs to up to two
pages for the TID fork during replaying XLOG_HEAP2_PRUNE since we
write it per heap pages. Probably we can process one by one.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/