Re: SIGSEGV, FPE fix in pg_controldata - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: SIGSEGV, FPE fix in pg_controldata
Date
Msg-id CAPpHfdt40HZ3uOzTER6L06xCNbqLmvzKUnDtdSzj3YEUfr73+w@mail.gmail.com
Whole thread Raw
In response to RE: SIGSEGV, FPE fix in pg_controldata  (Ilyasov Ian <ianilyasov@outlook.com>)
List pgsql-hackers
On Tue, Feb 4, 2025 at 6:36 PM Ilyasov Ian <ianilyasov@outlook.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
greatif 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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: should we have a fast-path planning for OLTP starjoins?
Next
From: Thomas Munro
Date:
Subject: Re: hash_search_with_hash_value is high in "perf top" on a replica