Re: Moving RestoreBlockImage from xlogreader.c to xlogutils.c
От | Fujii Masao |
---|---|
Тема | Re: Moving RestoreBlockImage from xlogreader.c to xlogutils.c |
Дата | |
Msg-id | CAHGQGwEPYLkH=iS2EFB75Y8qn1EqW6trvf9N5nRdcPo22EJo4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Moving RestoreBlockImage from xlogreader.c to xlogutils.c (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Moving RestoreBlockImage from xlogreader.c to xlogutils.c
|
Список | pgsql-hackers |
On Wed, Dec 24, 2014 at 10:41 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Wed, Dec 24, 2014 at 10:16 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >> On Wed, Dec 24, 2014 at 9:42 PM, Michael Paquier >> <michael.paquier@gmail.com> wrote: >>> Wouldn't it be better to declare it as a static routine in >>> xlogutils.c? If we keep it in xlogreader.c, I think that we should at >>> least wrap it with ifndef FRONTEND. >> >> If we do this, pg_lzcompress.c doesn't need to be moved to common for >> FPW compression patch which we're talking about in other thread. Right? > Yes. This refactoring came to my mind while re-thinking about the WAL > compression. This would also make more straight-forward the > implementation of hooks for compression and decompression. Fair enough. Anyway I wait for applying the patch which moves pg_lzcompress.c until we will have reached any consensus about this. >> DecodeXLogRecord() seems also a backend-only, so we should treat it >> in the same way as you proposed? Or pg_rewind uses that? > DecodeXLogRecord is used by XLogReadRecord, the latter being called by > pg_xlogdump and also pg_rewind, so it is not backend-only. Yeah, you're right. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: