On 2023-Nov-16, Robert Haas wrote: > On Thu, Nov 16, 2023 at 5:21 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > I meant code like this > > > > memcpy(&key.rlocator, rlocator, sizeof(RelFileLocator)); > > key.forknum = forknum; > > entry = blockreftable_lookup(brtab->hash, key); > > Ah, I hadn't thought about that. Another way of handling that might be > to add = {0} to the declaration of key. But I can do the initializer > thing too if you think it's better. I'm not sure if there's an > argument that the initializer might optimize better.
I think the {0} initializer is good enough, given a comment to indicate why. > > It's not clear to me if WalSummarizerCtl->pending_lsn if fulfilling some > > purpose or it's just a leftover from prior development. I see it's only > > read in an assertion ... Maybe if we think this cross-check is > > important, it should be turned into an elog? Otherwise, I'd remove it. > > I've been thinking about that. One thing I'm not quite sure about > though is introspection. Maybe there should be a function that shows > summarized_tli and summarized_lsn from WalSummarizerData, and maybe it > should expose pending_lsn too. True. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/