Re: POC: make mxidoff 64 bits
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: POC: make mxidoff 64 bits |
| Дата | |
| Msg-id | CAExHW5ucnoyjd6p7UVVhQTeV7hc8-vX81ti8f7sU0COqfUWzQg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: POC: make mxidoff 64 bits (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
| Ответы |
Re: POC: make mxidoff 64 bits
|
| Список | pgsql-hackers |
On Fri, Nov 28, 2025 at 6:35 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > > > I will continue reviewing it further. > There is duplication of code/functionality between server and pg_upgrade. With it we carry all the risks that come with code/functionality duplication like the copies going out of sync. There may be a valid reason to do that but it's not documented in the comments. At-least both mutlixact_new.c and slru_io.c are not as well commented as their server counterparts. I understand that the SLRU code in the server deals with shared memory which is not needed in pg_upgrade; pg_upgrade will not need more than one buffer in memory and pg_upgrade code doesn't need to deal with lock and it can not deal with locks. That means the code required by pg_upgrade is much simpler than that on the server. But there's also non-trivial code which is required in both the cases. WIll it be possible to extract parts of slru.c which deal with IO into slru_io.c, make it part of the core and then use it in pg_upgrade as well as slru.c? Or whether it's possible to make SLRU use local memory? And throwing some FRONTEND magic to the mix, we may be able to avoid duplication. Have we tried this or something else to avoid duplication? Sorry, if this has been discussed earlier. Please point me to the relevant discussion if so. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: