| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, michail(dot)nikolaev(at)gmail(dot)com, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
| Subject: | Re: BufferAlloc: don't take two simultaneous locks |
| Date: | 2022-04-14 16:29:53 |
| Message-ID: | CA+TgmoZkWfHpjSoA5e=BvTXvL4wtjW0yCWaMYNL2ExReG+7XeA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 14, 2022 at 11:27 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If it's not atomic, then you have to worry about what happens if you
> fail partway through, or somebody else changes relevant state while
> you aren't holding the lock. Maybe all those cases can be dealt with,
> but it will be significantly more fragile and more complicated (and
> therefore slower in isolation) than the current code. Is the gain in
> potential concurrency worth it? I didn't think so at the time, and
> the graphs upthread aren't doing much to convince me otherwise.
Those graphs show pretty big improvements. Maybe that's only because
what is being done is not actually safe, but it doesn't look like a
trivial effect.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-04-14 16:32:20 | Re: make MaxBackends available in _PG_init |
| Previous Message | Tom Lane | 2022-04-14 16:26:20 | Re: Intermittent buildfarm failures on wrasse |