| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM |
| Date: | 2023-11-16 20:52:10 |
| Message-ID: | CA+Tgmob6uBXWOaE52BS2g6P9ypmsAib+HHa8wmqm0PAe213a9w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Nov 16, 2023 at 3:49 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I think the main reason it's not all that bad, even when hitting this path, is
> that one stall every 8GB just isn't that much and that the stalls aren't that
> long - the leaf page fsm updates don't use the strategy, so they're still
> somewhat likely to be in s_b, and there's "just" ~2MB of FMS to read. I tried
> to reproduce it here, and it was a few ms, even though I dropped filesystem
> caches in a loop.
So just fix it in master then. If it turns out later there are worse
scenarios, you can back-patch then.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2023-11-16 21:05:19 | Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks |
| Previous Message | Daniel Gustafsson | 2023-11-16 20:49:54 | Adding deprecation notices to pgcrypto documentation |