On 2023-Nov-16, Robert Haas wrote:
> On Thu, Nov 16, 2023 at 5:21 AM Alvaro Herrera <alvherre@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/