Re: Remove fls(), use pg_bitutils.h facilities instead? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Remove fls(), use pg_bitutils.h facilities instead?
Date
Msg-id CA+hUKGKCFKbSthFQWbjDkDdap-LDU_2a16C1UyZ+EJRprn_8KA@mail.gmail.com
Whole thread Raw
In response to Re: Remove fls(), use pg_bitutils.h facilities instead?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove fls(), use pg_bitutils.h facilities instead?
List pgsql-hackers
On Thu, Jul 21, 2022 at 1:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> How is it sane to ask for a segment bin for zero pages?  Seems like
> something should have short-circuited such a case well before here.

It's intended.  There are two ways you can arrive here with n == 0:

* There's a special case in execParallel.c that creates a DSA segment
"in-place" with initial size dsa_minimum_size().  That's because we
don't know yet if we have any executor nodes that need a DSA segment
(Parallel Hash, Parallel Bitmap Heap Scan), so we create one with the
minimum amount of space other than the DSA control meta-data, so you
get an in-place segment 0 with 0 usable pages.  As soon as someone
tries to allocate one byte, the first external DSM segment will be
created.

* A full segment can be re-binned into slot 0.

On Thu, Jul 21, 2022 at 1:48 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Seems like passing a size_t to pg_leftmost_one_pos32 isn't great.
> It was just as wrong before (if the caller-supplied argument is
> indeed a size_t), but no time like the present to fix it.
>
> We could have pg_bitutils.h #define pg_leftmost_one_pos_size_t
> as the appropriate one of pg_leftmost_one_pos32/64, perhaps.

Yeah.

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Improve description of XLOG_RUNNING_XACTS
Next
From: Junwang Zhao
Date:
Subject: [PATCH v1] eliminate duplicate code in table.c