Re: Moving RestoreBlockImage from xlogreader.c to xlogutils.c
От | Fujii Masao |
---|---|
Тема | Re: Moving RestoreBlockImage from xlogreader.c to xlogutils.c |
Дата | |
Msg-id | CAHGQGwGLpTAaMmbRs=cCJ39Kh1WJvWrYdiSMaV4XPO634Hg8YQ@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 9:42 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > Hi all, > > Commit 2c03216d has introduced RestoreBlockImage to restore a page > from a given decoding state. ISTM that this is a backend-only > operation but it has been added in xlogreader.c which could be used as > well by frontend utilities like pg_xlogdump. > 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. > Thoughts? 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? DecodeXLogRecord() seems also a backend-only, so we should treat it in the same way as you proposed? Or pg_rewind uses that? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: