Re: Possible gaps/garbage in the output of XLOG reader - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Possible gaps/garbage in the output of XLOG reader
Date
Msg-id CAB7nPqR4HAL8SkH8hCSC0wde0NNhxwD0nVLx8rX-tZE5meDc_g@mail.gmail.com
Whole thread Raw
In response to Possible gaps/garbage in the output of XLOG reader  (Antonin Houska <ah@cybertec.at>)
Responses Re: [HACKERS] Possible gaps/garbage in the output of XLOG reader  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers
On Thu, Apr 9, 2015 at 7:05 PM, Antonin Houska <ah@cybertec.at> wrote:
> While playing with xlogreader, I was lucky enough to see one of the many
> record validations to fail. After having some fun with gdb, I found out that
> in some cases the reader does not enforce enough data to be in state->readBuf
> before copying into state->readRecordBuf starts. This should not happen if the
> callback always reads XLOG_BLCKSZ bytes, but in fact only *reqLen* is the
> mandatory size of the chunk delivered.
>
> There are probably various ways to fix this problem. Attached is what I did in
> my environment. I hit the problem on 9.4.1, but the patch seems to apply to
> master too.

This looks similar to what is discussed here:
https://www.postgresql.org/message-id/flat/CABOikdPsPByMiG6J01DKq6om2+BNkxHTPkOyqHM2a4oYwGKsqQ@mail.gmail.com
And there is a different patch which takes a lower-level approach, and
it seems to me cleaner approach in its way of calculating the record
offset when it goes through several XLOG pages.

Perhaps you could help review it? It is attached to the next commit fest.
-- 
Michael



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Reviewing freeze map code
Next
From: Amit Langote
Date:
Subject: Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116