On Wed, Aug 7, 2024 at 1:06 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> As I mentioned to you off-list, I feel like this needs some sort of
> recency bias. Certainly vacuum, and really almost any conceivable user
> of this facility, is going to care more about accurate answers for new
> data than for old data. If there's no recency bias, then I think that
> eventually answers for more recent LSNs will start to become less
> accurate, since they've got to share the data structure with more and
> more time from long ago. I don't think you've done anything about this
> in this version of the patch, but I might be wrong.
That makes sense. This version of the patch set doesn't have a recency
bias implementation. I plan to work on it but will need to do the
testing like you mentioned.
> One way to make the standby more accurately mimic the primary would be
> to base entries on the timestamp-LSN data that is already present in
> the WAL, i.e. {COMMIT|ABORT} [PREPARED] records. If you only added or
> updated entries on the primary when logging those records, the standby
> could redo exactly what the primary did. A disadvantage of this
> approach is that if there are no commits for a while then your mapping
> gets out of date, but that might be something we could just tolerate.
> Another possible solution is to log the changes you make on the
> primary and have the standby replay those changes. Perhaps I'm wrong
> to advocate for such solutions, but it feels error-prone to have one
> algorithm for the primary and a different algorithm for the standby.
> You now basically have two things that can break and you have to debug
> what went wrong instead of just one.
Your point about maintaining two different systems for creating the
time stream being error prone makes sense. Honestly logging the
contents of the LSNTimeStream seems like it will be the simplest to
maintain and understand. I was a bit apprehensive to WAL log one part
of a single stats structure (since the other stats aren't logged), but
I think explaining why that's done is easier than explaining separate
LSNTimeStream creation code for replicas.
- Melanie
