Re: [HACKERS] Error while copying a large file in pg_rewind
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Error while copying a large file in pg_rewind |
Дата | |
Msg-id | CAB7nPqSb0=jkBnGy0swZnmc36zHDXTgcFAD_f_CeOfykHOo1zg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Error while copying a large file in pg_rewind (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Error while copying a large file in pg_rewind
|
Список | pgsql-hackers |
On Fri, Jul 7, 2017 at 9:33 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Fri, Jul 7, 2017 at 4:31 PM, Kuntal Ghosh <kuntalghosh.2007@gmail.com> wrote: >> On Fri, Jul 7, 2017 at 7:49 AM, Michael Paquier >> <michael.paquier@gmail.com> wrote: >> I don't have any more inputs on this patch and it looks good to me. >> So, I'm moving the status to ready for committer. > > Thanks! > >>> At some point it would really make sense to group all things under the >>> same banner (64-b LO, pg_basebackup, and now pg_rewind). >>> >> +1. Implementation-wise, I prefer pg_recvint64 to fe_recvint64. > > So do I. That's a matter of taste I guess. Heikki, this bug is rather bad for anybody using pg_rewind with relation file sizes larger than 2GB as this corrupts data of instances. I think that you would be the best fit as a committer to look at this patch as you implemented the tool first, and it would be a bad idea to let that sit for a too long time. Could it be possible to spare a bit of your time at some point to look at it? -- Michael
В списке pgsql-hackers по дате отправления: