Re: Memory leak with XLogFileCopy since de768844 (WAL file with .partial)
От | Fujii Masao |
---|---|
Тема | Re: Memory leak with XLogFileCopy since de768844 (WAL file with .partial) |
Дата | |
Msg-id | CAHGQGwF-YYT5k=xosiYXZ=UDQhQcXP8i9TS0_rf9-4jYEQZDYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Memory leak with XLogFileCopy since de768844 (WAL file with .partial) (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Memory leak with XLogFileCopy since de768844 (WAL file
with .partial)
|
Список | pgsql-hackers |
On Tue, Jun 9, 2015 at 10:09 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Tue, Jun 9, 2015 at 6:25 AM, Heikki Linnakangas wrote: >> I'm still not sure if I should've just reverted that refactoring, to make >> XLogFileCopy() look the same in master and back-branches, which makes >> back-patching easier, or keep the refactoring, because it makes the code >> slightly nicer. But the current situation is the worst of both worlds: the >> interface of XLogFileCopy() is no better than it used to be, but it's >> different enough to cause merge conflicts. At this point, it's probably best >> to revert the code to look the same as in 9.4. > > That's a valid concern. What about the attached then? I think that it > is still good to keep upto to copy only data up to the switch point at > recovery exit. InstallXLogFileSegment() changes a bit as well because > of its modifications of arguments. Applied. Thanks! Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: