Skip to content

[pull] master from postgres:master #133

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jul 1, 2025
Merged

[pull] master from postgres:master #133

merged 6 commits into from
Jul 1, 2025

Conversation

pull[bot]
Copy link

@pull pull bot commented Jul 1, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.2)

Can you help keep this open source service alive? 💖 Please sponsor : )

amitlan and others added 6 commits July 1, 2025 13:13
Commit 19d8e23 added enum values with the prefix TU_, but a few
comments still referred to TUUI_, which was used in development
versions of the patches committed as 19d8e23.

Author: Yugo Nagata <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 16
The contrib module xml2/ has always been fuzzy with the cleanup of the
memory allocated by the calls internal to libxml2, even if there are
APIs in place giving a lot of control over the error behavior, all
located in the backend's xml.c.

The code paths fixed in the commit address multiple defects, while
sanitizing the code:
- In xpath.c, several allocations are done by libxml2 for
xpath_workspace, whose memory cleanup could go out of sight as it relied
on a single TRY/CATCH block done in pgxml_xpath().  workspace->res is
allocated by libxml2, and may finish by not being freed at all upon a
failure outside of a TRY area.  This code is refactored so as the
TRY/CATCH block of pgxml_xpath() is moved one level higher to its
callers, which are responsible for cleaning up the contents of a
workspace on failure.  cleanup_workspace() now requires a volatile
workspace, forcing as a rule that a TRY/CATCH block should be used.
- Several calls, like xmlStrdup(), xmlXPathNewContext(),
xmlXPathCtxtCompile(), etc. can return NULL on failures (for most of
them allocation failures.  These forgot to check for failures, or missed
that pg_xml_error_occurred() should be called, to check if an error is
already on the stack.
- Some memory allocated by libxml2 calls was freed in an incorrect way,
"resstr" in xslt_process() being one example.

The class of errors fixed here are for problems that are unlikely going
to happen in practice, so no backpatch is done.  The changes have
finished by being rather invasive, so it is perhaps not a bad thing to
be conservative and to keep these changes only on HEAD anyway.

Author: Michael Paquier <[email protected]>
Reported-by: Karavaev Alexey <[email protected]>
Reviewed-by: Jim Jones <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Switch MSVC to use the conforming preprocessor, using the
/Zc:preprocessor option.

This allows us to drop the alternative implementation of
VA_ARGS_NARGS() for the previous "traditional" preprocessor.

This also prepares the way for enabling C11 mode in the future, which
enables the conforming preprocessor by default.

This now requires Visual Studio 2019.  The installation documentation
is adjusted accordingly.

Discussion: https://www.postgresql.org/message-id/flat/01a69441-af54-4822-891b-ca28e05b215a%40eisentraut.org
There are different capitializations of "TOAST" around the
documentation and code.  This just changes a few places that were more
obviously inconsistent with similar phrases elsewhere.

Author: Peter Smith <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/CAHut+PtxXLJFhwJFvx+M=Ux8WGHU85XbT3nDqk-aAUS3E5ANCw@mail.gmail.com
There's a kernel bug in do_pages_stat(), affecting systems combining
64-bit kernel and 32-bit user space. The function splits the request
into chunks of 16 pointers, but forgets the pointers are 32-bit when
advancing to the next chunk. Some of the pointers get skipped, and
memory after the array is interpreted as pointers. The result is that
the produced status of memory pages is mostly bogus.

Systems combining 64-bit and 32-bit environments like this might seem
rare, but that's not the case - all 32-bit Debian packages are built in
a 32-bit chroot on a system with a 64-bit kernel.

This is a long-standing kernel bug (since 2010), affecting pretty much
all kernels, so it'll take time until all systems get a fixed kernel.
Luckily, we can work around the issue by chunking the requests the same
way do_pages_stat() does, at least on affected systems. We don't know
what kernel a 32-bit build will run on, so all 32-bit builds use chunks
of 16 elements (the largest chunk before hitting the issue).

64-bit builds are not affected by this issue, and so could work without
the chunking. But chunking has other advantages, so we apply chunking
even for 64-bit builds, with chunks of 1024 elements.

Reported-by: Christoph Berg <[email protected]>
Author: Christoph Berg <[email protected]>
Author: Bertrand Drouvot <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Context: https://marc.info/?l=linux-mm&m=175077821909222&w=2
Backpatch-through: 18
@pull pull bot locked and limited conversation to collaborators Jul 1, 2025
@pull pull bot added the ⤵️ pull label Jul 1, 2025
@pull pull bot merged commit 7fe2f67 into Haofei:master Jul 1, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants