Thread

  1. Re: Regression with large XML data input

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-25T17:50:38Z

    Erik Wienhold <ewie@ewie.name> writes:
    > On 2025-12-25 08:29 +0100, zengman wrote:
    >> After setting COPT=-Werror, compilation fails with the following errors (warnings are enforced as errors):
    >> xml.c: In function ‘xml_parse’:
    >> xml.c:1919:25: error: ‘xmlKeepBlanksDefault’ is deprecated [-Werror=deprecated-declarations]
    >> These deprecation warnings do not impact the test results in any way. 
    >> Therefore, I have attached a patch to suppress these specific warnings. 
    
    > The patch works when building with COPT=-Werror.  I guess the change is
    > okay since we already make use of -Wno-deprecated-declarations in
    > src/backend/jit/llvm/Makefile:
    
    > 	# LLVM 14 produces deprecation warnings.  We'll need to make some changes
    > 	# before the relevant functions are removed, but for now silence the warnings.
    > 	ifeq ($(GCC), yes)
    > 	LLVM_CFLAGS += -Wno-deprecated-declarations
    > 	endif
    
    Actually, that was a temporary hack that has long outlived its
    usefulness [1].  I don't love doing that for xml.c, because it
    would put a permanent block on our seeing future deprecation
    issues (until they become outright build failures).  Still...
    
    > But do we need the same guard for GCC here as well?
    
    Yeah, we would.  Non-gcc-alike compilers are unlikely to accept that
    switch.  We would also need a fix for the meson build system.
    
    > Alternatively, can you upgrade to libxml2 2.13.3+ which undeprecated
    > xmlKeepBlanksDefault?
    
    That would be my preferred answer, but after a quick census of the
    buildfarm I'm not sure we can get away with it.  The animals that
    are showing these warnings are all running RHEL 10 or clones of it,
    which is going to be in-support till 2035 or so.  Maybe Red Hat
    will upgrade to a newer libxml2 version than whatever they chose
    for RHEL 10.0, but I would not count on it.
    
    			regards, tom lane
    
    [1] https://www.postgresql.org/message-id/1407185.1766682319%40sss.pgh.pa.us