From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | thomas(dot)munro(at)gmail(dot)com |
Cc: | andres(at)anarazel(dot)de, tgl(at)sss(dot)pgh(dot)pa(dot)us, horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgsql: dshash: Add sequential scan support. |
Date: | 2022-07-04 08:31:46 |
Message-ID: | 20220704.173146.2012454546941903025.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
At Mon, 4 Jul 2022 14:55:43 +1200, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote in
> [Re-directing to -hackers]
>
> On Fri, Mar 11, 2022 at 2:27 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > It's per-backend state at least and just used for assertions. We could remove
> > it. Or stop checking it in places where it could be set wrongly: dshash_find()
> > and dshash_detach() couldn't check anymore, but the rest of the assertions
> > would still be valid afaics?
>
> Yeah, it's all for assertions... let's just remove it. Those
> assertions were useful to me at some stage in development but won't
> hold as well as I thought, at least without widespread PG_FINALLY(),
> which wouldn't be nice.
>
> *dsa_get_address() might need to adjust the memory map with system
> calls, which might fail. If you think of DSA as not only an allocator
> but also a poor man's user level virtual memory scheme to tide us over
> until we get threads, then this is a pretty low level kind of
> should-not-happen failure that is analogous on some level to SIGBUS or
> SIGSEGV or something like that, and we should PANIC. Then we could
> claim that dsa_get_address() is no-throw. At least, that was one
> argument I had with myself while investigating that strange Solaris
> shm_open() failure, but ... I lost the argument. It's quite an
> extreme position to take just to support these assertions, which are
> of pretty limited value.
>
> [1] https://www.postgresql.org/message-id/20220701232009.jcwxpl45bptaxv5n%40alap3.anarazel.de
FWIW, the discussion above is convincing to me and the patch looks good.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2022-07-04 10:46:11 | Re: pgsql: dshash: Add sequential scan support. |
Previous Message | Michael Paquier | 2022-07-04 06:49:54 | pgsql: Prevent write operations on large objects in read-only transacti |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-07-04 08:37:59 | Re: Re-order "disable_on_error" in tab-complete COMPLETE_WITH |
Previous Message | Kyotaro Horiguchi | 2022-07-04 08:27:44 | Re: Using PQexecQuery in pipeline mode produces unexpected Close messages |