Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
От | Ashutosh Sharma |
---|---|
Тема | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Дата | |
Msg-id | CAE9k0Pms34EW7D+bDoOMGGpPsvGkCLpx7M+KYmnH2S=Bh4ECxg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
|
Список | pgsql-hackers |
On Thu, Mar 10, 2022 at 10:18 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Mar 10, 2022 at 6:02 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > I have completely changed the logic for this refactoring. Basically, > > write_relmap_file(), is already having parameters to control whether > > to write wal, send inval and we are already passing the dbpath. > > Instead of making a new function I just pass one additional parameter > > to this function itself about whether we are creating a new map or not > > and I think with that changes are very less and this looks cleaner to > > me. Similarly for load_relmap_file() also I just had to pass the > > dbpath and memory for destination map. Please have a look and let me > > know your thoughts. > > It's not terrible, but how about something like the attached instead? > I think this has the effect of reducing the number of cases that the > low-level code needs to know about from 2 to 1, instead of making it > go up from 2 to 3. > Looks better, but why do you want to pass elevel to the load_relmap_file()? Are we calling this function from somewhere other than read_relmap_file()? If not, do we have any plans to call this function directly bypassing read_relmap_file for any upcoming patch? -- With Regards, Ashutosh Sharma.
В списке pgsql-hackers по дате отправления: