From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(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:19:32 |
Message-ID: | CA+TgmoYnmCpUQWUcxeg3dFXi+n8=N7CrZRbPgte6Jz=wYusVSQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-05-06 10:24:11 | Re: .ready and .done files considered harmful |
Previous Message | Dagfinn Ilmari Mannsåker | 2021-05-06 10:13:28 | Re: Why do we have perl and sed versions of Gen_dummy_probes? |