From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | tender wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Date: | 2024-01-29 06:01:32 |
Message-ID: | CAFiTN-ugEyi+ry7JAMbnnRpy=-+4kWnqFD5hqV5Y2nc4hs_sSA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 26, 2024 at 11:08 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> I've continued to review this and decided that I don't like the mess
> this patch proposes in order to support pg_commit_ts's deletion of all
> files. (Yes, I know that I was the one that proposed this idea. It's
> still a bad one). I'd like to change that code by removing the limit
> that we can only have 128 bank locks in a SLRU. To recap, the reason we
> did this is that commit_ts sometimes wants to delete all files while
> running (DeactivateCommitTs), and for this it needs to acquire all bank
> locks. Since going above the MAX_SIMUL_LWLOCKS limit is disallowed, we
> added the SLRU limit making multiple banks share lwlocks.
>
> I propose two alternative solutions:
>
> 1. The easiest is to have DeactivateCommitTs continue to hold
> CommitTsLock until the end, including while SlruScanDirectory does its
> thing. This sounds terrible, but considering that this code only runs
> when the module is being deactivated, I don't think it's really all that
> bad in practice. I mean, if you deactivate the commit_ts module and
> then try to read commit timestamp data, you deserve to wait for a few
> seconds just as a punishment for your stupidity.
I think this idea looks reasonable. I agree that if we are trying to
read commit_ts after deactivating it then it's fine to make it wait.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Sutou Kouhei | 2024-01-29 06:03:32 | Re: Make COPY format extendable: Extract COPY TO format implementations |
Previous Message | Dilip Kumar | 2024-01-29 05:56:40 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |