RE: [bug fix] Cascaded standby cannot start after a clean shutdown

From: Michael Paquier [mailto:michael(at)paquier(dot)xyz]
> I have been playing more with that this morning, and trying to tweak the
> XLOG reader so as the fetched page is zeroed where necessary does not help
> much. XLogReaderState->EndRecPtr is updated once the last record is set
> so it is possible to use it and zero the rest of the page which would prevent
> a lookup. But this is actually not wise for performance:
> - The data after EndRecPtr could be perfectly valid, so you could zero data
> which could be reused later.
> - It is necessary to drop the quick-exit checks in PageReadInternal.

First of all, thanks for your many experiments and ideas.

Yes, the above method doesn't work. The reason is not only performance but also correctness. After you zero-fill the remaining portion of state->readbuf based on state->EndRecPtr, you need to read the same page upon the request of the next WAL record. And that page read brings garbage again into state->readbuf. After all, the callers of ReadPageInternal() has to face the garbage.

> The WAL receiver approach also has a drawback. If WAL is streamed at full
> speed, then the primary sends data with a maximum of 6 WAL pages.
> When beginning streaming with a new segment, then the WAL sent stops at
> page boundary. But if you stop once in the middle of a page then you need
> to zero-fill the page until the current segment is finished streaming. So
> if the workload generates spiky WAL then the WAL receiver can would a lot
> of extra lseek() calls with the patch applied, while all the writes would
> be sequential on HEAD, so that's not performant-wise IMO.

Does even the non-cascading standby stop in the middle of a page? I thought the master always the whole WAL blocks without stopping in the middle of a page.

> Another idea I am thinking about would be to zero-fill the segments when
> recycled instead of being just renamed when doing InstallXLogFileSegment().
> This would also have the advantage of making the segments ahead more
> compressible, which is a gain for custom backups, and the WAL receiver does
> not need any tweaks as it would write the data on a clean file. Zero-filling
> the segments is done only when a new segment is created (see XLogFileInit).

Yes, I was (and am) inclined to take this approach; this is easy and clean, but not good for performance... I hope there's something which justifies this approach.

Regards
Takayuki Tsunakawa