From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: decoupling table and index vacuum |
Date: | 2021-05-06 10:42:14 |
Message-ID: | CAD21AoCdy7M1STR7BEE-o1YWWzAB0vdZufoXSOa6qObB6nD7MA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-05-06 10:46:56 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
Previous Message | Thomas Munro | 2021-05-06 10:35:30 | Anti-critical-section assertion failure in mcxt.c reached by walsender |