Re: [HACKERS] Proposal : For Auto-Prewarm.
От | Mithun Cy |
---|---|
Тема | Re: [HACKERS] Proposal : For Auto-Prewarm. |
Дата | |
Msg-id | CAD__OugubOs1Vy7kgF6xTjmEqTR4CrGAv8w+ZbaY_+MZeitukw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal : For Auto-Prewarm. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Proposal : For Auto-Prewarm.
|
Список | pgsql-hackers |
On Fri, Aug 18, 2017 at 9:43 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Aug 18, 2017 at 2:23 AM, Mithun Cy <mithun.cy@enterprisedb.com> wrote: > Ah, good catch. While I agree that there is probably no great harm > from skipping the lock here, I think it would be better to just avoid > throwing an error while we hold the lock. I think apw_dump_now() is > the only place where that could happen, and in the attached version, > I've fixed it so it doesn't do that any more. Independent of the > correctness issue, I think the code is easier to read this way. > > I also realize that it's not formally sufficient to use > PG_TRY()/PG_CATCH() here, because a FATAL would leave us in a bad > state. Changed to PG_ENSURE_ERROR_CLEANUP(). > >> 2) I also found one issue which was my own mistake in my previous patch 19. >> In "apw_dump_now" I missed calling FreeFile() on first write error, >> whereas on othercases I am already calling the same. >> ret = fprintf(file, "<<" INT64_FORMAT ">>\n", num_blocks); >> + if (ret < 0) >> + { >> + int save_errno = errno; >> + >> + unlink(transient_dump_file_path); > > Changed in the attached version. Thanks for the patch, I have tested the above fix now it works as described. From my test patch looks good, I did not find any other issues. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: