Possible gaps/garbage in the output of XLOG reader
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t32682psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 28, 2026 at 02:04 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t32682_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t32682_3 && git checkout t32682_3Patchset v3 (message #3) is on t32682_3
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
Attachments:
xlogreader_9.4.1.difftext/x-diffDownload+22-10
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:
/messages/by-id/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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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:
/messages/by-id/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]/messages/by-id/16062.1516189589@localhost. 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]/messages/by-id/16062.1516189589@localhost.
[1]: /messages/by-id/16062.1516189589@localhost
--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Web: https://www.cybertec-postgresql.com