SEO

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


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Florian G. Pflug wrote:
<snipped my own mail>

Please disregard - I was confusing xlogid with xlog segments, so
most of my mail was nonsense.

I've fixed my problem by storing not the EndRecPtr, but rather
the ReadRecPtr, in shmem and rereading the last already applied
record in my bgreplay process. Then I can just use ReadRecord(NULL),
and things Just Work.

Sorry for the noise & greetings
Florian Pflug


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster