Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
От | Dilip Kumar |
---|---|
Тема | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
Дата | |
Msg-id | CAFiTN-vKRvkJVB6S13sm_4Kwt93Nif60s+deB5YamgZ+304ROA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Fri, Aug 21, 2020 at 10:20 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Aug 21, 2020 at 9:14 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Thu, Aug 20, 2020 at 5:42 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > On Thu, Aug 20, 2020 at 2:30 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > > > > > > > Right, I think this can happen if one has changed those by BufFileSeek > > > > before doing truncate. We should fix that case as well. > > > > > > Right. > > > > > > > > I will work on those along with your other comments and > > > > > submit the updated patch. > > > > > > I have fixed this in the attached patch along with your other > > > comments. I have also attached a contrib module that is just used for > > > testing the truncate API. > > > > > > > Few comments: > > ============== > > +void > > +BufFileTruncateShared(BufFile *file, int fileno, off_t offset) > > { > > .. > > + if ((i != fileno || offset == 0) && i != 0) > > + { > > + SharedSegmentName(segment_name, file->name, i); > > + FileClose(file->files[i]); > > + if (!SharedFileSetDelete(file->fileset, segment_name, true)) > > + ereport(ERROR, > > + (errcode_for_file_access(), > > + errmsg("could not delete shared fileset \"%s\": %m", > > + segment_name))); > > + numFiles--; > > + newOffset = MAX_PHYSICAL_FILESIZE; > > + > > + if (i == fileno) > > + newFile--; > > + } > > > > Here, shouldn't it be i <= fileno? Because we need to move back the > > curFile up to newFile whenever curFile is greater than newFile > > > > I think now I have understood why you have added this condition but > probably a comment on the lines "This is required to indicate that we > have removed the given fileno" would be better for future readers. Okay. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: