This is the main PostgreSQL git repository. http://git.postgresql.org/cgit/postgresql.git/atom?h=REL_10_STABLE 2024-11-27T03:47:29Z 2024-11-27T03:47:29Z Thomas Munro 2024-11-27T02:43:18Z urn:sha1:f4e8f137bfb08a664c8288824c1e36b5143ac875 Branches before 16 can't be compiled with a C23 compiler (see deprecation warnings silenced by commit f9a56e72, and non-back-patchable changes made in 16 by commit 1c27d16e). Test __STDC_VERSION__, and if it's above C17 then try appending -std=gnu17. The test is done with the user's CFLAGS, so an acceptable language version can also be configured manually that way. This is done in branches 15 and older, back to 9.2, per policy of keeping them buildable with modern tools. Discussion: https://postgr.es/m/87o72eo9iu.fsf%40gentoo.org 2024-06-26T11:25:35Z Andrew Dunstan 2024-06-26T11:01:47Z urn:sha1:320534f8f25bf5aa2de4ad1f561b71219cb4e5ff Commit 4c1532763a removed some redundant uses of 'use 5.008001;' in perl scripts, including in plperl's plc_perlboot.pl. Because it made other changes it wasn't backpatched. However, now this is causing a failure on back branches when built with bleeding edge perl. Therefore, backpatch just that part of it which removed those uses, from 15 all the way down to 9.2, which is the earliest version currently built in the buildfarm. per report from Alexander Lakhin Discussion: https://postgr.es/m/4cc2ee93-e03c-8e13-61ed-412e7e6ff19d@gmail.com 2023-01-17T21:01:20Z Tom Lane 2023-01-17T21:00:39Z urn:sha1:c18c12c983a84d55e58b176969782c7ffac3272b test_extensions' test_ext_cine extension has the same upgrade hazard as test_ext7: the regression test leaves it in an updated state from which no downgrade path to default is provided. This causes the update_extensions.sql script helpfully provided by pg_upgrade to fail. So drop it in cross-version-upgrade testing. Not entirely sure how come I didn't hit this in testing yesterday; possibly I'd built the upgrade reference databases with testmodules-install-check disabled. Backpatch to v10 where this module was introduced. 2023-01-17T01:35:53Z Tom Lane 2023-01-17T01:35:53Z urn:sha1:ddd89df26b9779e1b6415cdf3617563072bfa716 To test pg_upgrade across major PG versions, we have to be able to modify or drop any old objects with no-longer-supported properties, and we have to be able to deal with cosmetic changes in pg_dump output. Up to now, the buildfarm and pg_upgrade's own test infrastructure had separate implementations of the former, and we had nothing but very ad-hoc rules for the latter (including an arbitrary threshold on how many lines of unchecked diff were okay!). This patch creates a Perl module that can be shared by both those use-cases, and adds logic that deals with pg_dump output diffs in a much more tightly defined fashion. This largely supersedes previous efforts in commits 0df9641d3, 9814ff550, and 62be9e4cd, which developed a SQL-script-based solution for the task of dropping old objects. There was nothing fundamentally wrong with that work in itself, but it had no basis for solving the output-formatting problem. The most plausible way to deal with formatting is to build a Perl module that can perform editing on the dump files; and once we commit to that, it makes more sense for the same module to also embed the knowledge of what has to be done for dropping old objects. Back-patch versions of the helper module as far as 9.2, to support buildfarm animals that still test that far back. It's also necessary to back-patch PostgreSQL/Version.pm, because the new code depends on that. I fixed up pg_upgrade's 002_pg_upgrade.pl in v15, but did not look into back-patching it further than that. Tom Lane and Andrew Dunstan Discussion: https://postgr.es/m/891521.1673657296@sss.pgh.pa.us 2022-11-17T15:39:20Z Noah Misch 2022-11-17T15:35:06Z urn:sha1:ec6ba191ce5aba32606171b2bda0d73b53381af0 This restores compatibility with the not-yet-released successor of version 20220807.0. Back-patch to 9.4, which introduced this code. Reviewed by Andrew Dunstan. Discussion: https://postgr.es/m/20221117061805.GA4020280@rfd.leadboat.com 2022-11-09T00:39:58Z Michael Paquier 2022-11-09T00:39:58Z urn:sha1:8f5d4ee6c5a1de2601934139c974bc09bc42edab Upstream SELinux has recently marked security_context_t as officially deprecated, causing warnings with -Wdeprecated-declarations. This is considered as legacy code for some time now by upstream as security_context_t got removed from most of the code tree during the development of 2.3 back in 2014. This removes all the references to security_context_t in sepgsql/ to be consistent with SELinux, fixing the warnings. Note that this does not impact the minimum version of libselinux supported. This has been applied first as 1f32136 for 14~, but no other branches got the call. This is in line with the recent project policy to have no warnings in branches where builds should still be supported (9.2~ as of today). Per discussion with Tom Lane and Álvaro Herrera. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/20200813012735.GC11663@paquier.xyz Discussion: https://postgr.es/m/20221103181028.raqta27jcuypor4l@alvherre.pgsql Backpatch-through: 9.2 2022-11-07T21:51:10Z Tom Lane 2022-11-07T21:51:10Z urn:sha1:02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4 2022-11-07T12:50:33Z Peter Eisentraut 2022-11-07T12:50:33Z urn:sha1:d26829e3f76ac58872bd57374cce6bd41d1e40cf Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: cb81d65ab5de3d0a84d73bdf72d3c97bf5ea596b 2022-11-06T16:07:28Z Tom Lane 2022-11-06T16:07:28Z urn:sha1:e964827b23ef5ebb43585c978b799b8c2f892cc4 2022-11-03T16:01:57Z Tom Lane 2022-11-03T16:01:57Z urn:sha1:5f3cec77b1b5d79100b127d0555a3e3d42e464da If a syntax error occurred in a SQL-language or PL/pgSQL-language CREATE FUNCTION or DO command executed in a logical replication worker, we'd suffer a null pointer dereference or assertion failure. That seems like a rather contrived case, but nonetheless worth fixing. The cause is that function_parse_error_transpose assumes it must be executing within the context of a Portal, but logical/worker.c doesn't create a Portal since it's not running the standard executor. We can just back off the hard Assert check and make it fail gracefully if there's not an ActivePortal. (I have a feeling that the aggressive check here was my fault originally, probably because I wasn't sure if the case would always hold and wanted to find out. Well, now we know.) The hazard seems to exist in all branches that have logical replication, so back-patch to v10. Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane Discussion: https://postgr.es/m/b570c367-ba38-95f3-f62d-5f59b9808226@inbox.ru Discussion: https://postgr.es/m/adf0452f-8c6b-7def-d35e-ab516c80088e@inbox.ru