Hi contributors,
I'm working on a logical decoding improvement and running into a persistent build issue where LTO (-flto=thin) is optimizing out my LogicalWaitForWal function, even though there are explicit calls to it.
The situation:
Function LogicalWaitForWal() is defined in src/backend/replication/logical/logical.c
It's called directly from logical_read_xlog_page_cv() in the same file
logical_read_xlog_page_cv is assigned as the page_read callback via XL_ROUTINE in multiple places in logical.c
The function appears in the object file (nm logical.o shows it)
But it's completely absent from the final binary (nm postgres shows nothing)
What I've tried so far:
Direct calls: The function is called explicitly from logical_read_xlog_page_cv
Attributes: __attribute__((used)), visibility("default"), retain
Global references:
c
void *_force_keep __attribute__((used)) = (void *)LogicalWaitForWal;
Makefile overrides: Attempted to disable LTO for just logical.o
Various force-linkage patterns: Global function pointers, used arrays, etc.
The function signature:
c
XLogRecPtr LogicalWaitForWal(XLogRecPtr targetLSN);
It's called here in logical_read_xlog_page_cv:
c
flushptr = LogicalWaitForWal(targetPagePtr + reqLen);
And logical_read_xlog_page_cv is assigned via:
c
XL_ROUTINE(.page_read = logical_read_xlog_page_cv, ...)
The puzzling part is that both functions are in the same compilation unit, there's an explicit call, yet LTO still removes LogicalWaitForWal.
Is there a PostgreSQL-specific pattern or macro I should be using to ensure functions aren't optimized out when they're called via function pointers assigned in structs?
Thank you for your time!
Thanks,
Arkady Skvorcov
