Hi, On 2023-06-14 16:10:38 -0400, Robert Haas wrote: > On Wed, Jun 14, 2023 at 3:47 PM Andres Freund <and...@anarazel.de> wrote: > > Could we just recompute the WAL summary for the [redo, end of chunk] for the > > relevant summary file? > > I'm not understanding how that would help. If we were going to compute > a WAL summary on the fly rather than waiting for one to show up on > disk, what we'd want is [end of last WAL summary that does exist on > disk, redo].
Oh, right. > But I'm not sure that's a great approach, because that LSN gap might be > large and then we're duplicating a lot of work that the summarizer has > probably already done most of. I guess that really depends on what the summary granularity is. If you create a separate summary every 32MB or so, recomputing just the required range shouldn't be too bad. > > FWIW, I like the idea of a special WAL record at that point, independent of > > this feature. It wouldn't be a meaningful overhead compared to the cost of a > > checkpoint, and it seems like it'd be quite useful for debugging. But I can > > see uses going beyond that - we occasionally have been discussing > > associating > > additional data with redo points, and that'd be a lot easier to deal with > > during recovery with such a record. > > > > I don't really see a performance and concurrency angle right now - what are > > you wondering about? > > I'm not really sure. I expect Dilip would be happy to post his patch, > and if you'd be willing to have a look at it and express your concerns > or lack thereof, that would be super valuable. Will do. Adding me to CC: might help, I have a backlog unfortunately :(. Greetings, Andres Freund