Re: Minimal logical decoding on standbys

On Mon, 10 Jun 2019 at 10:37, Amit Khandekar <amitdkhan.pg@gmail.com> wrote:
>
> On Tue, 4 Jun 2019 at 21:28, Andres Freund <andres@anarazel.de> wrote:
> >
> > Hi,
> >
> > On 2019-06-04 15:51:01 +0530, Amit Khandekar wrote:
> > > After giving more thought on this, I think it might make sense to
> > > arrange for the xl_running_xact record to be sent from master to the
> > > standby, when a logical slot is to be created on standby. How about
> > > standby sending a new message type to the master, requesting for
> > > xl_running_xact record ? Then on master, ProcessStandbyMessage() will
> > > process this new message type and call LogStandbySnapshot().
> >
> > I think that should be a secondary feature. You don't necessarily know
> > the upstream master, as the setup could be cascading one.
> Oh yeah, cascading setup makes it more complicated.
>
> > I think for
> > now just having to wait, perhaps with a comment to manually start a
> > checkpoint, ought to suffice?
>
> Ok.
>
> Since this requires the test to handle the
> fire-create-slot-and-then-fire-checkpoint-from-master actions, I was
> modifying the test file to do this. After doing that, I found that the
> slave gets an assertion failure in XLogReadRecord()=>XRecOffIsValid().
> This happens only when the restart_lsn is set to ReplayRecPtr.
> Somehow, this does not happen when I manually create the logical slot.
> It happens only while running testcase. Working on it ...

Like I mentioned above, I get an assertion failure for
Assert(XRecOffIsValid(RecPtr)) while reading WAL records looking for a
start position (DecodingContextFindStartpoint()). This is because in
CreateInitDecodingContext()=>ReplicationSlotReserveWal(), I now set
the logical slot's restart_lsn to XLogCtl->lastReplayedEndRecPtr. And
just after bringing up slave, lastReplayedEndRecPtr's initial values
are in this order : 0/2000028, 0/2000060, 0/20000D8, 0/2000100,
0/3000000, 0/3000060. You can see that 0/3000000 is not a valid value
because it points to the start of a WAL block, meaning it points to
the XLog page header (I think it's possible because it is 1 + endof
last replayed record, which can be start of next block). So when we
try to create a slot when it's in that position, then XRecOffIsValid()
fails while looking for a starting point.

One option I considered was : If lastReplayedEndRecPtr points to XLog
page header, get a position of the first record on that WAL block,
probably with XLogFindNextRecord(). But it is not trivial because
while in ReplicationSlotReserveWal(), XLogReaderState is not created
yet. Or else, do you think we can just increment the record pointer by
doing something like (lastReplayedEndRecPtr % XLOG_BLCKSZ) +
SizeOfXLogShortPHD() ?

Do you think that we can solve this using some other approach ? I am
not sure whether it's only the initial conditions that cause
lastReplayedEndRecPtr value to *not* point to a valid record, or is it
just a coincidence and that lastReplayedEndRecPtr can also have such a
value any time afterwards. If it's only possible initially, we can
just use GetRedoRecPtr() instead of lastReplayedEndRecPtr if
lastReplayedEndRecPtr is invalid.

-- 
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company