Thread: RE: SIGSEGV, FPE fix in pg_controldata

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.

>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
ifsomeone could tell me the story behind signed segment size as I see it is better unsigned. 


Kind regards,
Ian Ilyasov.

Junior Software Developer at Postgres Professional

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