Postgres Pro
Downloads
Home   >   mailing lists

Thread: Possible gaps/garbage in the output of XLOG reader

Possible gaps/garbage in the output of XLOG reader

From
Antonin Houska
Date:
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.

--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at
Attachment

Re: Possible gaps/garbage in the output of XLOG reader

From
Michael Paquier
Date:
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

Re: [HACKERS] Possible gaps/garbage in the output of XLOG reader

From
Antonin Houska
Date:
Michael Paquier <michael.paquier@gmail.com> wrote:

> 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.

I don't see an overlap. The problem I reported is still there. Attached is a
patch for the current HEAD.

Attached is also a patch that I use to simulate the problem. It includes this
hunk

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
new file mode 100644
index e42b828..e7b56b6
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
*************** retry:
*** 11648,11654 ****
        }

        pgstat_report_wait_start(WAIT_EVENT_WAL_READ);
!       if (read(readFile, readBuf, XLOG_BLCKSZ) != XLOG_BLCKSZ)
        {
                char            fname[MAXFNAMELEN];

--- 11648,11654 ----
        }

        pgstat_report_wait_start(WAIT_EVENT_WAL_READ);
!       if (read(readFile, readBuf, readLen) != readLen)
        {
                char            fname[MAXFNAMELEN];


that I posted in [1]. When the reproduce.diff was applied (but not
xlogreader_readbuf_gap.diff), I could fire the contained Assert(readOff ==
XLOG_BLCKSZ) statement this way:

1. Create a new cluster.

2. Create another one and setup streaming replication.

3. Run regression test on master.

After some time the Assert() statement fired on the standby.

There are probably simpler scenarios but here I want to stress that the
problem is related to [1].


[1] https://www.postgresql.org/message-id/16062.1516189589%40localhost

--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Web: https://www.cybertec-postgresql.com
Attachment