From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | ReadRecord, EndRecPtr and XLOG_SWITCH |
Date: | 2007-07-09 21:57:24 |
Message-ID: | 4692AF44.4060409@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
When ReadRecord encounters an XLOG_SWITCH record, it does
EndRecPtr.xrecoff += XLogSegSize - 1;
EndRecPtr.xrecoff -= EndRecPtr.xrecoff % XLogSegSize;
which seems to set xrecoff to either 0 (if it was 0)
or to XLogSegSize (if it was > 0).
Note that xrecoff == XLogSegSize is kind of "denormalized" -
the normalized version would have xrecoff == 0, and xlogid = xlogid+1
Passing this "denormalized" EndRecPtr to ReadRecord again
to read the next record than triggers a PANIC
("invalid record offset at ??/10000000"). Passing NULL to ReadRecord
to read the next record works, because it takes care to align the
EndRecPtr to the next page, thereby fixing the "denormalization".
Is there a reason not to do the same for non-NULL arguments to
ReadRecord? Or is there some failure case that the current
behaviour protects against?
The reason I stumbled over this is that I want to restart archive
recovery from a "bgreplay" process - I tried passing the EndRecPtr
via shmem, and using it as my initial argument to ReadRecord, and
thereby stumbled over this behaviour.
greetings, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2007-07-09 22:34:15 | Re: ReadRecord, EndRecPtr and XLOG_SWITCH |
Previous Message | Gregory Stark | 2007-07-09 21:38:24 | Re: PQescapeBytea* version for parameters |