From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Antonin Houska <ah(at)cybertec(dot)at> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible gaps/garbage in the output of XLOG reader |
Date: | 2016-06-14 07:22:04 |
Message-ID: | CAB7nPqR4HAL8SkH8hCSC0wde0NNhxwD0nVLx8rX-tZE5meDc_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 9, 2015 at 7:05 PM, Antonin Houska <ah(at)cybertec(dot)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(at)mail(dot)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2016-06-14 08:06:53 | Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116 |
Previous Message | Amit Kapila | 2016-06-14 07:11:00 | Re: ERROR: ORDER/GROUP BY expression not found in targetlist |