Re: longfin and tamandua aren't too happy but I'm not sure why

On Tue, Sep 27, 2022 at 4:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
> >   * frame #0: 0x000000010a36af8c postgres`ParseCommitRecord(info='\x80', xlrec=0x00007fa0678a8090, parsed=0x00007ff7b5c50e78) at xactdesc.c:102:30
>
> Okay, so the problem is this: by widening RelFileNumber to 64 bits,
> you have increased the alignment requirement of struct RelFileLocator,
> and thereby also SharedInvalidationMessage, to 8 bytes where it had
> been 4.  longfin's alignment check is therefore expecting that
> xl_xact_twophase will likewise be 8-byte-aligned, but it isn't:

Yeah, I reached the same conclusion.

> There is a second problem that I am going to hold your feet to the
> fire about:
>
> (lldb) p sizeof(SharedInvalidationMessage)
> (unsigned long) $1 = 24
>
> We have sweated a good deal for a long time to keep that struct
> to 16 bytes.  I do not think 50% bloat is acceptable.

I noticed that problem, too.

The attached patch, which perhaps you can try out, fixes the alignment
issue and also reduces the size of SharedInvalidationMessage from 24
bytes back to 20 bytes. I do not really see a way to do better than
that. We use 1 type byte, 3 bytes for the backend ID, 4 bytes for the
database OID, and 4 bytes for the tablespace OID. Previously, we then
used 4 bytes for the relfilenode, but now we need 7, and there's no
place from which we can plausibly steal those bits, at least not as
far as I can see. If you have ideas, I'm all ears.

Also, I don't really know what problem you think it's going to cause
if that structure gets bigger. If we increased the size from 16 bytes
even all the way to 32 or 64 bytes, what negative impact do you think
that would have? It would use a little bit more shared memory, but on
modern systems I doubt it would be enough to get excited about. The
bigger impact would probably be that it would make commit records a
bit bigger since those carry invalidations as payload. That is not
great, but I think it only affects commit records for transactions
that do DDL, so I'm struggling to see that as a big performance
problem.

--
Robert Haas
EDB: http://www.enterprisedb.com