Re: decoupling table and index vacuum

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: decoupling table and index vacuum
Date: 2021-05-06 12:32:29
Message-ID: CAFiTN-vLXk6QhKjxy-HxiA9Z5uBDvq_9uJJNBCU_hxeLfE0grg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 6 May 2021 at 4:12 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:

> On Thu, May 6, 2021 at 7:19 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Thu, May 6, 2021 at 5:02 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
> wrote:
> > > 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.
> >
> > It seems like we do need to hold them at the same time, because
> > typically for a WAL record you lock all the buffers, modify them all
> > while writing the WAL record, and then unlock them all.
> >
> > Now maybe there's some argument that we can dodge that requirement
> > here, but I have reservations about departing from the usual locking
> > pattern. It's easier to reason about the behavior when everybody
> > follows the same set of rules.
>
> Yes, agreed. I was thinking of replaying WAL, not writing WAL.

Right, I was pointing to while writing the WAL.

> --
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2021-05-06 12:40:18 Re: [BUG]"FailedAssertion" reported in lazy_scan_heap() when running logical replication
Previous Message Michael Paquier 2021-05-06 12:12:37 Re: Small issues with CREATE TABLE COMPRESSION