Re: SIGSEGV, FPE fix in pg_controldata

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Ilyasov Ian <ianilyasov(at)outlook(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SIGSEGV, FPE fix in pg_controldata
Date: 2025-02-04 21:14:21
Message-ID: CAPpHfdt40HZ3uOzTER6L06xCNbqLmvzKUnDtdSzj3YEUfr73+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 4, 2025 at 6:36 PM Ilyasov Ian <ianilyasov(at)outlook(dot)com> wrote:
>
> Thank you for your answer, Alexander!
> I like your patch and it looks similar to my first version of it before I came up to the possible segment size problem.

Ok.

> >Also, I don't think we should change
> segment size to uint32 as it's already defined as int in awfully a lot
> of places
>
> I agree that changing segment size type is probably out of this thread and problem scope, but suppose it would be great if someone could tell me the story behind signed segment size as I see it is better unsigned.

I didn't dig too deep into history, but it seems to be just
historically so. Given now, segment size is defined as int in awfully
a lot of places, there should be a motivation to change all of that
(changing it just in pg_control_data, but leaving everything else "as
is" doesn't make sense to me). Now we have WalSegMaxSize equals to
1GB and signed int is enough to store value within this range. So, if
we would badly need to increase WalSegMaxSize, that would give the
motivation to change, but I don't see that.

------
Regards,
Alexander Korotkov
Supabase

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-02-04 21:22:06 Re: hash_search_with_hash_value is high in "perf top" on a replica
Previous Message Tomas Vondra 2025-02-04 20:56:27 Re: should we have a fast-path planning for OLTP starjoins?