Re: Make relfile tombstone files conditional on WAL level
От | Dilip Kumar |
---|---|
Тема | Re: Make relfile tombstone files conditional on WAL level |
Дата | |
Msg-id | CAFiTN-sPUy2FQutXEqY2Dzi_Mve+Jo6Q3NgG6VYc4mR5yimV5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Make relfile tombstone files conditional on WAL level (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Make relfile tombstone files conditional on WAL level
|
Список | pgsql-hackers |
On Mon, Jan 31, 2022 at 7:36 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Mon, Jan 31, 2022 at 9:04 AM Robert Haas <robertmhaas@gmail.com> wrote: > > On Mon, Jan 31, 2022 at 12:29 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > the main one currently we do not have uint8 data > > > type only int8 is there so I have used int8 for storing relfilenode + > > > forknumber. > > > > I'm confused. We use int8 in tons of places, so I feel like it must exist. > > Rather, we use uint8 in tons of places, so I feel like it must exist. Hmm, at least pg_type doesn't have anything with a name like uint8. postgres[101702]=# select oid, typname from pg_type where typname like '%int8'; oid | typname ------+--------- 20 | int8 1016 | _int8 (2 rows) postgres[101702]=# select oid, typname from pg_type where typname like '%uint%'; oid | typname -----+--------- (0 rows) I agree that we are using 8 bytes unsigned int multiple places in code as uint64. But I don't see it as an exposed data type and not used as part of any exposed function. But we will have to use the relfilenode in the exposed c function e.g. binary_upgrade_set_next_heap_relfilenode(). -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: