Re: making relfilenodes 56 bits

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: making relfilenodes 56 bits
Дата
Msg-id CA+TgmobZmhx8F1ajnb1A0pBe=u3+LCHN48BMZ968fcDjiiLMtQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: making relfilenodes 56 bits  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: making relfilenodes 56 bits  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: making relfilenodes 56 bits  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: making relfilenodes 56 bits  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Thu, Jul 28, 2022 at 10:29 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > I have done some cleanup in 0002 as well, basically, earlier we were
> > storing the result of the BufTagGetRelFileLocator() in a separate
> > variable which is not required everywhere.  So wherever possible I
> > have avoided using the intermediate variable.
>
> I'll have a look at this next.

I was taught that when programming in C one should avoid returning a
struct type, as BufTagGetRelFileLocator does. I would have expected it
to return void and take an argument of type RelFileLocator * into
which it writes the results. On the other hand, I was also taught that
one should avoid passing a struct type as an argument, and smgropen()
has been doing that since Tom Lane committed
87bd95638552b8fc1f5f787ce5b862bb6fc2eb80 all the way back in 2004. So
maybe this isn't that relevant any more on modern compilers? Or maybe
for small structs it doesn't matter much? I dunno.

Other than that, I think your 0002 looks fine.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michail Nikolaev
Дата:
Сообщение: Re: Slow standby snapshot
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated