pgsql: Fix RBM_ZERO_AND_LOCK.
Fix RBM_ZERO_AND_LOCK. Commit 210622c6 accidentally zeroed out pages even if they were found in the buffer pool. It should always lock the page, but it should only zero pages that were not already valid. Otherwise, concurrent readers that hold only a pin could see corrupted page contents changing under their feet. While here, rename ZeroAndLockBuffer() to match the RBM_ flag name. Also restore a some useful comments lost by 210622c6's refactoring, and add some new ones to clarify why we need to use the BM_IO_IN_PROGRESS infrastructure despite not doing I/O. Reported-by: Noah Misch Reported-by: Alexander Lakhin Reviewed-by: Alvaro Herrera (earlier version) Reviewed-by: Robert Haas (earlier version) Discussion: https://postgr.es/m/20240512171658.7e.nmi...@google.com Discussion: https://postgr.es/m/7ed10231-ce47-03d5-d3f9-4aea0dc7d5a4%40gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e656657f2b93a96b83fd4038ec5120c5ec9845e5 Modified Files -- src/backend/storage/buffer/bufmgr.c | 88 - 1 file changed, 67 insertions(+), 21 deletions(-)
pgsql: jit: Remove {llvm-config,clang}-N configure probes.
jit: Remove {llvm-config,clang}-N configure probes.
Previously we searched for llvm-config-N and clang-N as well as the
unversioned names, and maintained a list of expected values of N. There
doesn't seem to be any reason to think that the default llvm-config and
clang won't be good enough, and if they aren't, they can be overridden
with LLVM_CONFIG and CLANG, so let's stop maintaining that list.
The list had not been updated since LLVM 7 with no complaints, so commit
820b5af73dc probably should have just removed it when dropping support
for 7, instead of trying to be helpful by bringing it up to date with
recent version numbers.
The Meson build system didn't have that, so no change there.
Suggested-by: Peter Eisentraut
Discussion:
https://postgr.es/m/CA%2BhUKG%2BSOP-aR%3DYF_n0dtXGWeCy6x%2BCn-RMWURU5ySQdmeKW1Q%40mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4dd29b683334739168f60df520dcc9218b6fead7
Modified Files
--
config/llvm.m4 | 4 ++--
configure | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
pgsql: Skip citext_utf8 test on Windows.
Skip citext_utf8 test on Windows. On other Windows build farm animals it is already skipped because they don't use UTF-8 encoding. On "hamerkop", UTF-8 is used, and then the test fails. It is not clear to me (a non-Windows person looking only at buildfarm evidence) whether Windows is less sophisticated than other OSes and doesn't know how to downcase Turkish İ with the standard Unicode database, or if it is more sophisticated than other systems and uses locale-specific behavior like ICU does. Whichever the reason, the result is the same: we need to skip the test on Windows, just as we already do for ICU, at least until a Windows-savvy developer comes up with a better idea. The technique for detecting the OS is borrowed from collate.windows.win1252.sql. This was anticipated by commit c2e8bd27, but the problem only surfaced when Windows build farm animals started using Meson. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CA%2BhUKGJ1LeC3aE2qQYTK95rFVON3ZVoTQpTKJqxkHdtEyawH4A%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cff4e5a36bfe1191a688c5eaff7ba095588ba732 Modified Files -- contrib/citext/expected/citext_utf8.out | 3 +++ contrib/citext/expected/citext_utf8_1.out | 3 +++ contrib/citext/sql/citext_utf8.sql| 3 +++ 3 files changed, 9 insertions(+)
Re: pgsql: Fix potential stack overflow in incremental backup.
On Thu, Apr 11, 2024 at 2:28 PM Michael Paquier wrote: > + * file just as if this were not an incremental backup. The contents of the > + * relative_block_numbers array is unspecified in this case. > > Perhaps you mean s/is/are/ here? The contents are what's not > specified. Thanks, fixed. Duh.
pgsql: Fix grammar.
Fix grammar. Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZhdKqj5DwoOzirFv%40paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/942219996c632ae9e66c2c4a759e93abc92014ff Modified Files -- src/backend/backup/basebackup_incremental.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix potential stack overflow in incremental backup.
Fix potential stack overflow in incremental backup. The user can set RELSEG_SIZE to a high number at compile time, so we can't use it to control the size of an array on the stack: it could be many gigabytes in size. On closer inspection, we don't really need that intermediate array anyway. Let's just write directly into the output array, and then perform the absolute->relative adjustment in place. This fixes new code from commit dc212340058. Reviewed-by: Robert Haas Discussion: https://postgr.es/m/CA%2BhUKG%2B2hZ0sBztPW4mkLfng0qfkNtAHFUfxOMLizJ0BPmi5%2Bg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d8f5acbdb9b22106db583e3cbb177d34e6b18eeb Modified Files -- src/backend/backup/basebackup_incremental.c | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-)
Re: pgsql: Refactor libpq state machine for negotiating encryption
On Thu, Apr 11, 2024 at 11:25 AM Tom Lane wrote: > Thomas Munro writes: > > If -Dssl=none and -Dgssapi=disabled, compilation of fe-connect.c > > fails: call to undeclared function 'encryption_negotiation_failed'. I > > didn't look too hard, but maybe ENABLE_GSS and USE_GSS are confused? > > For me, configure --with-gssapi fails like that, but the other three > combinations of --with-openssl and --with-gssapi compile OK. I don't > find it terribly surprising that the buildfarm isn't covering that > combination ... Oops, right, correction to my report: it is indeed -Dssl=none -Dgssapi=enabled that is broken, not the other combinations.
Re: pgsql: Refactor libpq state machine for negotiating encryption
On Mon, Apr 8, 2024 at 1:25 PM Heikki Linnakangas wrote: > Refactor libpq state machine for negotiating encryption > > This fixes the few corner cases noted in commit 705843d294, as shown > by the changes in the test. > > Author: Heikki Linnakangas, Matthias van de Meent > Reviewed-by: Jacob Champion If -Dssl=none and -Dgssapi=disabled, compilation of fe-connect.c fails: call to undeclared function 'encryption_negotiation_failed'. I didn't look too hard, but maybe ENABLE_GSS and USE_GSS are confused?
pgsql: Fix illegal attribute propagation in LLVM JIT.
Fix illegal attribute propagation in LLVM JIT. Commit 72559438 started copying more attributes from AttributeTemplate to the functions we generate on the fly. In the case of deform functions, which return void, this meant that "noundef", from AttributeTemplate's return value (a Datum) was copied to a void type. Older LLVM releases were OK with that, but LLVM 18 crashes. Update our llvm_copy_attributes() function to skip copying the attribute for the return value, if the target function returns void. Thanks to Dmitry Dolgov for help chasing this down. Back-patch to all supported releases, like 72559438. Reported-by: Pavel Stehule Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Discussion: https://postgr.es/m/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch%2Bw98OxYg%40mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01b55203ace02bb02049cd147f63b407f3911ca5 Modified Files -- src/backend/jit/llvm/llvmjit.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: Fix illegal attribute propagation in LLVM JIT.
Fix illegal attribute propagation in LLVM JIT. Commit 72559438 started copying more attributes from AttributeTemplate to the functions we generate on the fly. In the case of deform functions, which return void, this meant that "noundef", from AttributeTemplate's return value (a Datum) was copied to a void type. Older LLVM releases were OK with that, but LLVM 18 crashes. Update our llvm_copy_attributes() function to skip copying the attribute for the return value, if the target function returns void. Thanks to Dmitry Dolgov for help chasing this down. Back-patch to all supported releases, like 72559438. Reported-by: Pavel Stehule Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Discussion: https://postgr.es/m/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch%2Bw98OxYg%40mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4f90750b53266e561dfcb6956d5d045d8d4b7b94 Modified Files -- src/backend/jit/llvm/llvmjit.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: Fix illegal attribute propagation in LLVM JIT.
Fix illegal attribute propagation in LLVM JIT. Commit 72559438 started copying more attributes from AttributeTemplate to the functions we generate on the fly. In the case of deform functions, which return void, this meant that "noundef", from AttributeTemplate's return value (a Datum) was copied to a void type. Older LLVM releases were OK with that, but LLVM 18 crashes. Update our llvm_copy_attributes() function to skip copying the attribute for the return value, if the target function returns void. Thanks to Dmitry Dolgov for help chasing this down. Back-patch to all supported releases, like 72559438. Reported-by: Pavel Stehule Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Discussion: https://postgr.es/m/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch%2Bw98OxYg%40mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7fe32eaa4a878500280ed7d33ce711c06b6939ff Modified Files -- src/backend/jit/llvm/llvmjit.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: Fix illegal attribute propagation in LLVM JIT.
Fix illegal attribute propagation in LLVM JIT. Commit 72559438 started copying more attributes from AttributeTemplate to the functions we generate on the fly. In the case of deform functions, which return void, this meant that "noundef", from AttributeTemplate's return value (a Datum) was copied to a void type. Older LLVM releases were OK with that, but LLVM 18 crashes. Update our llvm_copy_attributes() function to skip copying the attribute for the return value, if the target function returns void. Thanks to Dmitry Dolgov for help chasing this down. Back-patch to all supported releases, like 72559438. Reported-by: Pavel Stehule Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Discussion: https://postgr.es/m/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch%2Bw98OxYg%40mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/74992929a79e2606fbc4d579c3fad04a890eda04 Modified Files -- src/backend/jit/llvm/llvmjit.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: Fix illegal attribute propagation in LLVM JIT.
Fix illegal attribute propagation in LLVM JIT. Commit 72559438 started copying more attributes from AttributeTemplate to the functions we generate on the fly. In the case of deform functions, which return void, this meant that "noundef", from AttributeTemplate's return value (a Datum) was copied to a void type. Older LLVM releases were OK with that, but LLVM 18 crashes. Update our llvm_copy_attributes() function to skip copying the attribute for the return value, if the target function returns void. Thanks to Dmitry Dolgov for help chasing this down. Back-patch to all supported releases, like 72559438. Reported-by: Pavel Stehule Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Discussion: https://postgr.es/m/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch%2Bw98OxYg%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf1cfe77ed49a4929695ba6c0367f784f2f6a10c Modified Files -- src/backend/jit/llvm/llvmjit.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: Fix illegal attribute propagation in LLVM JIT.
Fix illegal attribute propagation in LLVM JIT. Commit 72559438 started copying more attributes from AttributeTemplate to the functions we generate on the fly. In the case of deform functions, which return void, this meant that "noundef", from AttributeTemplate's return value (a Datum) was copied to a void type. Older LLVM releases were OK with that, but LLVM 18 crashes. Update our llvm_copy_attributes() function to skip copying the attribute for the return value, if the target function returns void. Thanks to Dmitry Dolgov for help chasing this down. Back-patch to all supported releases, like 72559438. Reported-by: Pavel Stehule Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Discussion: https://postgr.es/m/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch%2Bw98OxYg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/53c8d6c9f157f2bc8211b8de02417e55fefddbc7 Modified Files -- src/backend/jit/llvm/llvmjit.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
Re: pgsql: Custom reloptions for table AM
Hi Alexander, I think this is uninitialised memory: ../pgsql/src/backend/postmaster/autovacuum.c:2988:33: runtime error: load of value 80, which is not a valid value for type '_Bool' #0 0x56010b3b6e47 in relation_needs_vacanalyze ../pgsql/src/backend/postmaster/autovacuum.c:2988 #1 0x56010b3b7745 in do_autovacuum ../pgsql/src/backend/postmaster/autovacuum.c:2023 #2 0x56010b3ba1a3 in AutoVacWorkerMain ../pgsql/src/backend/postmaster/autovacuum.c:1569 #3 0x56010b3c0aa6 in postmaster_child_launch ../pgsql/src/backend/postmaster/launch_backend.c:265 #4 0x56010b3c36b4 in StartChildProcess ../pgsql/src/backend/postmaster/postmaster.c:3928 #5 0x56010b3c6775 in StartAutovacuumWorker ../pgsql/src/backend/postmaster/postmaster.c:3997 #6 0x56010b3c6775 in process_pm_pmsignal ../pgsql/src/backend/postmaster/postmaster.c:3809 #7 0x56010b3c6775 in ServerLoop ../pgsql/src/backend/postmaster/postmaster.c:1667 #8 0x56010b3c8ca5 in PostmasterMain ../pgsql/src/backend/postmaster/postmaster.c:1372 #9 0x56010b1f458e in main ../pgsql/src/backend/main/main.c:197 #10 0x7f23b7e456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #11 0x7f23b7e45784 in __libc_start_main_impl ../csu/libc-start.c:360 #12 0x56010ad5a270 in _start (/home/bf/bf-build/tamandua/HEAD/pgsql.build/tmp_install/home/bf/bf-build/tamandua/HEAD/inst/bin/postgres+0x8b3270) (BuildId: 17e96a9e15a2c22c2062d2cefc7586aaea64b144) Or from CI: ../src/backend/postmaster/autovacuum.c:2988:33: runtime error: load of value 26, which is not a valid value for type '_Bool' ==43234==Using libbacktrace symbolizer. #0 0x556ee56de975 in relation_needs_vacanalyze ../src/backend/postmaster/autovacuum.c:2988 #1 0x556ee56df9e0 in do_autovacuum ../src/backend/postmaster/autovacuum.c:2023 #2 0x556ee56e1ada in AutoVacWorkerMain ../src/backend/postmaster/autovacuum.c:1569 #3 0x556ee56e8175 in postmaster_child_launch ../src/backend/postmaster/launch_backend.c:265 #4 0x556ee56ea1f3 in StartChildProcess ../src/backend/postmaster/postmaster.c:3928 #5 0x556ee56ede6f in StartAutovacuumWorker ../src/backend/postmaster/postmaster.c:3997 #6 0x556ee56ee3b0 in process_pm_pmsignal ../src/backend/postmaster/postmaster.c:3809 #7 0x556ee56ee889 in ServerLoop ../src/backend/postmaster/postmaster.c:1667 #8 0x556ee56f0478 in PostmasterMain ../src/backend/postmaster/postmaster.c:1372 #9 0x556ee550fb70 in main ../src/backend/main/main.c:197 #10 0x7f81c899cd09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09) #11 0x556ee505f249 in _start (/tmp/cirrus-ci-build/build/tmp_install/usr/local/pgsql/bin/postgres+0x8ea249)
pgsql: Add pg_buffercache_evict() function for testing.
Add pg_buffercache_evict() function for testing. When testing buffer pool logic, it is useful to be able to evict arbitrary blocks. This function can be used in SQL queries over the pg_buffercache view to set up a wide range of buffer pool states. Of course, buffer mappings might change concurrently so you might evict a block other than the one you had in mind, and another session might bring it back in at any time. That's OK for the intended purpose of setting up developer testing scenarios, and more complicated interlocking schemes to give stronger guararantees about that would likely be less flexible for actual testing work anyway. Superuser-only. Author: Palak Chaturvedi Author: Thomas Munro (docs, small tweaks) Reviewed-by: Nitin Jadhav Reviewed-by: Andres Freund Reviewed-by: Cary Huang Reviewed-by: Cédric Villemain Reviewed-by: Jim Nasby Reviewed-by: Maxim Orlov Reviewed-by: Thomas Munro Reviewed-by: Melanie Plageman Discussion: https://postgr.es/m/calfch19pw48zwwzuorspsav9hqt0upyabpc4boz4w+c7ff5...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/13453eedd3f692f8dcf8e334396eee84f00fdde2 Modified Files -- contrib/pg_buffercache/Makefile| 2 +- contrib/pg_buffercache/meson.build | 1 + .../pg_buffercache/pg_buffercache--1.4--1.5.sql| 6 +++ contrib/pg_buffercache/pg_buffercache.control | 2 +- contrib/pg_buffercache/pg_buffercache_pages.c | 20 +++ doc/src/sgml/pgbuffercache.sgml| 39 +++--- src/backend/storage/buffer/bufmgr.c| 63 ++ src/include/storage/bufmgr.h | 2 + 8 files changed, 127 insertions(+), 8 deletions(-)
pgsql: Use streaming I/O in ANALYZE.
Use streaming I/O in ANALYZE. The ANALYZE command prefetches and reads sample blocks chosen by a BlockSampler algorithm. Instead of calling [Prefetch|Read]Buffer() for each block, ANALYZE now uses the streaming API introduced in b5a9b18cd0. Author: Nazir Bilal Yavuz Reviewed-by: Melanie Plageman Reviewed-by: Andres Freund Reviewed-by: Jakub Wartak Reviewed-by: Heikki Linnakangas Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/flat/CAN55FZ0UhXqk9v3y-zW_fp4-WCp43V8y0A72xPmLkOM%2B6M%2BmJg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/041b96802efa33d2bc9456f2ad946976b92b5ae1 Modified Files -- src/backend/access/heap/heapam_handler.c | 29 ++- src/backend/commands/analyze.c | 85 ++-- src/include/access/heapam.h | 5 +- 3 files changed, 43 insertions(+), 76 deletions(-)
pgsql: Use streaming I/O in sequential scans.
Use streaming I/O in sequential scans. Instead of calling ReadBuffer() for each block, heap sequential scans and TID range scans now use the streaming API introduced in b5a9b18cd0. Author: Melanie Plageman Reviewed-by: Andres Freund Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/flat/CAAKRu_YtXJiYKQvb5JsA2SkwrsizYLugs4sSOZh3EAjKUg%3DgEQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b7b0f3f27241e424b7103397489464d907cef2c4 Modified Files -- src/backend/access/heap/heapam.c | 235 +++ src/include/access/heapam.h | 15 +++ 2 files changed, 177 insertions(+), 73 deletions(-)
pgsql: Fix if/while thinko in read_stream.c edge case.
Fix if/while thinko in read_stream.c edge case. When we determine that a wanted block can't be combined with the current pending read, it's time to start that read to get it out of the way. An "if" in that code path should have been a "while", because it might take more than one go in case of partial reads. This was only broken for smaller ranges, as the more common case of io_combine_limit-sized ranges is handled earlier in the code and knows how to loop, hiding the bug for a while. Discovered while testing large parallel sequential scans of partially cached tables. The ramp-up-and-down block allocator for parallel scans could hit the problem case and skip some blocks near the end that should have been streamed. Defect in commit b5a9b18c. Discussion: https://postgr.es/m/CA%2BhUKG%2Bh8Whpv0YsJqjMVkjYX%2B80fTVc6oi-V%2BzxJvykLpLHYQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/158f5819236806b7c9cab323658c231e9371c458 Modified Files -- src/backend/storage/aio/read_stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Allow BufferAccessStrategy to limit pin count.
Allow BufferAccessStrategy to limit pin count. While pinning extra buffers to look ahead, users of strategies are in danger of using too many buffers. For some strategies, that means "escaping" from the ring, and in others it means forcing dirty data to disk very frequently with associated WAL flushing. Since external code has no insight into any of that, allow individual strategy types to expose a clamp that should be applied when deciding how many buffers to pin at once. Reviewed-by: Andres Freund Reviewed-by: Melanie Plageman Discussion: https://postgr.es/m/CAAKRu_aJXnqsyZt6HwFLnxYEBgE17oypkxbKbT1t1geE_wvH2Q%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3bd8439ed628c7e9ac250b1a042d9044303c37e7 Modified Files -- src/backend/storage/aio/read_stream.c | 5 + src/backend/storage/buffer/freelist.c | 42 +++ src/include/storage/bufmgr.h | 1 + 3 files changed, 48 insertions(+)
pgsql: Increase default vacuum_buffer_usage_limit to 2MB.
Increase default vacuum_buffer_usage_limit to 2MB. The BAS_VACUUM ring size has been 256kB since commit d526575f introduced the mechanism 17 years ago. Commit 1cbbee03 recently made it configurable but retained the traditional default. The correct default size has been debated for years, but 256kB is certainly very small. VACUUM soon needs to write back data it dirtied only 32 blocks ago, which usually requires flushing the WAL. New experiments in prefetching pages for VACUUM exacerbated the problem by crashing into dirty data even sooner. Let's make the default 2MB. That's 1.6% of the default toy buffer pool size, and 0.2% of 1GB, which would be a considered a small shared_buffers setting for a real system these days. Users are still free to set the GUC to a different value. Reviewed-by: Andres Freund Discussion: https://postgr.es/m/20240403221257.md4gfki3z75cdyf6%40awork3.anarazel.de Discussion: https://postgr.es/m/CA%2BhUKGLY4Q4ZY4f1rvnFtv6%2BPkjNf8MejdPkcju3Qii9DYqqcQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/98f320eb2ef05072b6fe67fcdcdc26c226e6cea4 Modified Files -- doc/src/sgml/config.sgml | 2 +- src/backend/storage/buffer/freelist.c | 2 +- src/backend/utils/init/globals.c | 2 +- src/backend/utils/misc/guc_tables.c | 2 +- src/backend/utils/misc/postgresql.conf.sample | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-)
pgsql: Improve read_stream.c's fast path.
Improve read_stream.c's fast path. The "fast path" for well cached scans that don't do any I/O was accidentally coded in a way that could only be triggered by pg_prewarm's usage pattern, which starts out with a higher distance because of the flags it passes in. We want it to work for streaming sequential scans too, once that patch is committed. Adjust. Reviewed-by: Melanie Plageman Discussion: https://postgr.es/m/CA%2BhUKGKXZALJ%3D6aArUsXRJzBm%3Dqvc4AWp7%3DiJNXJQqpbRLnD_w%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aa1e8c206454d666ab600050022aef2c3c390f69 Modified Files -- src/backend/storage/aio/read_stream.c | 75 +++ 1 file changed, 31 insertions(+), 44 deletions(-)
Re: pgsql: Implement pg_wal_replay_wait() stored procedure
On Wed, Apr 3, 2024 at 9:42 AM Alexander Korotkov wrote: > On Tue, Apr 2, 2024 at 10:58 PM Alexander Korotkov > wrote: > > Implement pg_wal_replay_wait() stored procedure > > I'm trying to figure out if this failure could be related to this commit... > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae=2024-04-02%2020%3A24%3A55 I think you might need to move WaitLSNShmemInit() down to CreateOrAttachShmemStructs(), otherwise -DEXEC_BACKEND build dies with a NULL pointer. (Huh, why doesn't that animal show a backtrace?)
pgsql: Provide vectored variant of ReadBuffer().
Provide vectored variant of ReadBuffer(). Break ReadBuffer() up into two steps. StartReadBuffers() and WaitReadBuffers() give us two main advantages: 1. Multiple consecutive blocks can be read with one system call. 2. Advice (hints of future reads) can optionally be issued to the kernel ahead of time. The traditional ReadBuffer() function is now implemented in terms of those functions, to avoid duplication. A new GUC io_combine_limit is defined, and the functions for limiting per-backend pin counts are made into public APIs. Those are provided for use by callers of StartReadBuffers(), when deciding how many buffers to read at once. The following commit will add a higher level mechanism for doing that automatically with a practical interface. With some more infrastructure in later work, StartReadBuffers() could be extended to start real asynchronous I/O instead of just issuing advice and leaving WaitReadBuffers() to do the work synchronously. Author: Thomas Munro Author: Andres Freund (some optimization tweaks) Reviewed-by: Melanie Plageman Reviewed-by: Heikki Linnakangas Reviewed-by: Nazir Bilal Yavuz Reviewed-by: Dilip Kumar Reviewed-by: Andres Freund Tested-by: Tomas Vondra Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6ut5tum2g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/210622c60e1a9db2e2730140b8106ab57d259d15 Modified Files -- doc/src/sgml/config.sgml | 14 + src/backend/storage/buffer/bufmgr.c | 726 ++ src/backend/storage/buffer/localbuf.c | 14 +- src/backend/utils/misc/guc_tables.c | 14 + src/backend/utils/misc/postgresql.conf.sample | 1 + src/include/storage/bufmgr.h | 55 ++ src/tools/pgindent/typedefs.list | 2 + 7 files changed, 605 insertions(+), 221 deletions(-)
pgsql: Provide API for streaming relation data.
Provide API for streaming relation data. Introduce an abstraction allowing relation data to be accessed as a stream of buffers, with an implementation that is more efficient than the equivalent sequence of ReadBuffer() calls. Client code supplies a callback that can say which block number it wants next, and then consumes individual buffers one at a time from the stream. This division puts read_stream.c in control of how far ahead it can see and allows it to read clusters of neighboring blocks with StartReadBuffers(). It also issues POSIX_FADV_WILLNEED advice ahead of time when random access is detected. Other variants of I/O stream will be proposed in future work (for example to support recovery, whose LsnReadQueue device in xlogprefetcher.c is a distant cousin of this code and should eventually be replaced by this), but this basic API is sufficient for many common executor usage patterns involving predictable access to a single fork of a single relation. Several patches using this API are proposed separately. This stream concept is loosely based on ideas from Andres Freund on how we should pave the way for later work on asynchronous I/O. Author: Thomas Munro Author: Heikki Linnakangas (contributions) Author: Melanie Plageman (contributions) Suggested-by: Andres Freund Reviewed-by: Heikki Linnakangas Reviewed-by: Melanie Plageman Reviewed-by: Nazir Bilal Yavuz Reviewed-by: Andres Freund Tested-by: Tomas Vondra Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6ut5tum2g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b5a9b18cd0bc6f0124664999b31a00a264d16913 Modified Files -- src/backend/storage/Makefile | 2 +- src/backend/storage/aio/Makefile | 14 + src/backend/storage/aio/meson.build | 5 + src/backend/storage/aio/read_stream.c | 812 ++ src/backend/storage/meson.build | 1 + src/include/storage/read_stream.h | 63 +++ src/tools/pgindent/typedefs.list | 2 + 7 files changed, 898 insertions(+), 1 deletion(-)
pgsql: Use streaming I/O in pg_prewarm.
Use streaming I/O in pg_prewarm. Instead of calling ReadBuffer() repeatedly, use the new streaming interface. This commit provides a very simple example of such a transformation. Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6ut5tum2g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3a352df05e65de740b4a375a0ecbcae97a1f6196 Modified Files -- contrib/pg_prewarm/pg_prewarm.c | 40 +++- 1 file changed, 39 insertions(+), 1 deletion(-)
pgsql: ci: Use a RAM disk and more CPUs on FreeBSD.
ci: Use a RAM disk and more CPUs on FreeBSD. Run the tests in a RAM disk. It's still a UFS file system and is backed by 20GB of disk, but this avoids a lot of I/O. Even though we disable fsync, our tests do a lot of directory manipulations, some of which force file system meta-data to disk and flush slow device write caches on UFS. This was a bottleneck preventing effective scaling beyond 2 CPUs. Now we can use 4 CPUs like on other OSes, for a huge speedup. Reviewed-by: Maxim Orlov Discussion: https://postgr.es/m/CA%2BhUKG%2BFXLcEg1dyTqJjDiNQ8pGom4KrJj4wF38C90thti9dVA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0265e5c120e0971a9c50a1e27ce4cb847c15a1bf Modified Files -- .cirrus.tasks.yml | 8 +++- src/tools/ci/gcp_freebsd_repartition.sh | 24 +++- 2 files changed, 14 insertions(+), 18 deletions(-)
pgsql: Add --copy-file-range option to pg_upgrade.
Add --copy-file-range option to pg_upgrade. The copy_file_range() system call is available on at least Linux and FreeBSD, and asks the kernel to use efficient ways to copy ranges of a file. Options available to the kernel include sharing block ranges (similar to --clone mode), and pushing down block copies to the storage layer. For automated testing, see PG_TEST_PG_UPGRADE_MODE. (Perhaps in a later commit we could consider setting this mode for one of the CI targets.) Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/CA%2BhUKGKe7Hb0-UNih8VD5UNZy5-ojxFb3Pr3xSBBL8qj2M2%3DdQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d93627bcbe5001750e7611f0e637200e2d81dcff Modified Files -- configure | 2 +- configure.ac | 1 + doc/src/sgml/ref/pgupgrade.sgml| 13 +++ meson.build| 1 + src/bin/pg_upgrade/TESTING | 4 +- src/bin/pg_upgrade/check.c | 3 ++ src/bin/pg_upgrade/file.c | 78 ++ src/bin/pg_upgrade/option.c| 7 +++- src/bin/pg_upgrade/pg_upgrade.h| 4 ++ src/bin/pg_upgrade/relfilenumber.c | 8 src/include/pg_config.h.in | 3 ++ 11 files changed, 120 insertions(+), 4 deletions(-)
pgsql: Fix overflow in Windows replacement pg_pread/pg_pwrite.
Fix overflow in Windows replacement pg_pread/pg_pwrite. When calling the Windows file I/O APIs there is an implicit conversion from size_t to DWORD, which could overflow. Clamp the size at 1GB to avoid that. Not a really a live bug as we don't expect anything in PostgreSQL to call with such large values. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/1672202.1703441340%40sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1e013746544bd1f9df70f5547894fd72719c4b85 Modified Files -- src/port/win32pread.c | 3 +++ src/port/win32pwrite.c | 3 +++ 2 files changed, 6 insertions(+)
pgsql: Return ssize_t in fd.c I/O functions.
Return ssize_t in fd.c I/O functions. In the past, FileRead() and FileWrite() used types based on the Unix read() and write() functions from before C and POSIX standardization, though not exactly (we had int for amount instead of unsigned). In commit 2d4f1ba6 we changed to the appropriate standard C types, just like the modern POSIX functions they wrap, but again not exactly: the return type stayed as int. In theory, a ssize_t value could be returned by the underlying call that is too large for an int. That wasn't really a live bug, because we don't expect PostgreSQL code to perform reads or writes of gigabytes, and OSes probably apply internal caps smaller than that anyway. This change is done on the principle that the return might as well follow the standard interfaces consistently. Reported-by: Tom Lane Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/1672202.1703441340%40sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/653b55b57081dc6fb8c75d61870c5fdc8c8554cc Modified Files -- src/backend/storage/file/fd.c | 8 src/include/storage/fd.h | 8 2 files changed, 8 insertions(+), 8 deletions(-)
pgsql: Fix gai_strerror() thread-safety on Windows.
Fix gai_strerror() thread-safety on Windows. Commit 5579388d removed code that supplied a fallback implementation of getaddrinfo(), which was dead code on modern systems. One tiny piece of the removed code was still doing something useful on Windows, though: that OS's own gai_strerror()/gai_strerrorA() function returns a pointer to a static buffer that it overwrites each time, so it's not thread-safe. In rare circumstances, a multi-threaded client program could get an incorrect or corrupted error message. Restore the replacement gai_strerror() function, though now that it's only for Windows we can put it into a win32-specific file and cut it down to the errors that Windows documents. The error messages here are taken from FreeBSD, because Windows' own messages seemed too verbose. Back-patch to 16. Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/CA%2BhUKGKz%2BF9d2PTiXwfYV7qJw%2BWg2jzACgSDgPizUw7UG%3Di58A%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0460e4ecc0fa532468331a4b71ad0fbe8ff1a416 Modified Files -- configure | 6 + configure.ac| 1 + src/include/port/win32/sys/socket.h | 8 +++ src/port/meson.build| 1 + src/port/win32gai_strerror.c| 45 + src/tools/msvc/Mkvcbuild.pm | 1 + 6 files changed, 62 insertions(+)
pgsql: Fix gai_strerror() thread-safety on Windows.
Fix gai_strerror() thread-safety on Windows. Commit 5579388d removed code that supplied a fallback implementation of getaddrinfo(), which was dead code on modern systems. One tiny piece of the removed code was still doing something useful on Windows, though: that OS's own gai_strerror()/gai_strerrorA() function returns a pointer to a static buffer that it overwrites each time, so it's not thread-safe. In rare circumstances, a multi-threaded client program could get an incorrect or corrupted error message. Restore the replacement gai_strerror() function, though now that it's only for Windows we can put it into a win32-specific file and cut it down to the errors that Windows documents. The error messages here are taken from FreeBSD, because Windows' own messages seemed too verbose. Back-patch to 16. Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/CA%2BhUKGKz%2BF9d2PTiXwfYV7qJw%2BWg2jzACgSDgPizUw7UG%3Di58A%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/65f438471b769f6b9706a386028f81df065d0a25 Modified Files -- configure | 6 + configure.ac| 1 + src/include/port/win32/sys/socket.h | 8 +++ src/port/meson.build| 1 + src/port/win32gai_strerror.c| 45 + 5 files changed, 61 insertions(+)
pgsql: jit: Require at least LLVM 10.
jit: Require at least LLVM 10. Remove support for older LLVM versions. The default on common software distributions will be at least LLVM 10 when PostgreSQL 17 ships. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/CA%2BhUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY%3DiA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/820b5af73dcc6a5d0db6a98a62a6b859e5d107b6 Modified Files -- config/llvm.m4 | 10 +++--- configure | 43 +++ doc/src/sgml/installation.sgml | 4 +-- meson.build | 2 +- src/backend/jit/llvm/llvmjit.c | 57 ++ src/backend/jit/llvm/llvmjit_error.cpp | 10 -- src/backend/jit/llvm/llvmjit_expr.c | 6 +--- src/backend/jit/llvm/llvmjit_inline.cpp | 38 ++-- src/backend/jit/llvm/llvmjit_wrap.cpp | 61 - src/include/jit/llvmjit.h | 17 - src/include/pg_config.h.in | 12 --- 11 files changed, 17 insertions(+), 243 deletions(-)
pgsql: Track LLVM 18 changes.
Track LLVM 18 changes. A function was given a newly standard name from C++20 in LLVM 16. Then LLVM 18 added a deprecation warning for the old name, and it is about to ship, so it's time to adjust that. Back-patch to all supported releases. Discussion: https://www.postgresql.org/message-id/CA+hUKGLbuVhH6mqS8z+FwAn4=5dhs0bawmemz3b+iyhwkc4...@mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d060cb65880fe950774c6f3f9facf0f87504bfb3 Modified Files -- src/backend/jit/llvm/llvmjit_inline.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Track LLVM 18 changes.
Track LLVM 18 changes. A function was given a newly standard name from C++20 in LLVM 16. Then LLVM 18 added a deprecation warning for the old name, and it is about to ship, so it's time to adjust that. Back-patch to all supported releases. Discussion: https://www.postgresql.org/message-id/CA+hUKGLbuVhH6mqS8z+FwAn4=5dhs0bawmemz3b+iyhwkc4...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/70a82f40ab4044b1fa690b0b97ec54b7a5e18647 Modified Files -- src/backend/jit/llvm/llvmjit_inline.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Track LLVM 18 changes.
Track LLVM 18 changes. A function was given a newly standard name from C++20 in LLVM 16. Then LLVM 18 added a deprecation warning for the old name, and it is about to ship, so it's time to adjust that. Back-patch to all supported releases. Discussion: https://www.postgresql.org/message-id/CA+hUKGLbuVhH6mqS8z+FwAn4=5dhs0bawmemz3b+iyhwkc4...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/364283c92e4a4183fb4f80ce4ec9ba96007b6632 Modified Files -- src/backend/jit/llvm/llvmjit_inline.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Track LLVM 18 changes.
Track LLVM 18 changes. A function was given a newly standard name from C++20 in LLVM 16. Then LLVM 18 added a deprecation warning for the old name, and it is about to ship, so it's time to adjust that. Back-patch to all supported releases. Discussion: https://www.postgresql.org/message-id/CA+hUKGLbuVhH6mqS8z+FwAn4=5dhs0bawmemz3b+iyhwkc4...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/67f7aaa38172155ab2d8a2248e87b5d0b7dc6444 Modified Files -- src/backend/jit/llvm/llvmjit_inline.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Track LLVM 18 changes.
Track LLVM 18 changes. A function was given a newly standard name from C++20 in LLVM 16. Then LLVM 18 added a deprecation warning for the old name, and it is about to ship, so it's time to adjust that. Back-patch to all supported releases. Discussion: https://www.postgresql.org/message-id/CA+hUKGLbuVhH6mqS8z+FwAn4=5dhs0bawmemz3b+iyhwkc4...@mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/60ba7cae7cc758f09899429d1134a14adc35fd94 Modified Files -- src/backend/jit/llvm/llvmjit_inline.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Track LLVM 18 changes.
Track LLVM 18 changes. A function was given a newly standard name from C++20 in LLVM 16. Then LLVM 18 added a deprecation warning for the old name, and it is about to ship, so it's time to adjust that. Back-patch to all supported releases. Discussion: https://www.postgresql.org/message-id/CA+hUKGLbuVhH6mqS8z+FwAn4=5dhs0bawmemz3b+iyhwkc4...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d282e88e50521a457fa1b36e55f43bac02a3167f Modified Files -- src/backend/jit/llvm/llvmjit_inline.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Provide vectored variants of smgrread() and smgrwrite().
Provide vectored variants of smgrread() and smgrwrite(). smgrreadv() and smgrwritev() and their md.c implementations call FileReadV() and FileWriteV(). A range of disk blocks beginning at 'blocknum' and extending for 'nblocks' can be scattered to or gathered from multiple buffers with a single system call. The traditional smgrread() and smgrwrite() functions are implemented in terms of the new functions. Later commits will introduce calls with nblocks > 1, but the following behavioral changes can be seen already: * After a short transfer we'll now retry until we eventually read 0 bytes (= EOF) or get ENOSPC, EDQUOT, EFBIG etc, where previously we would infer the reason. Retrying is consistent with xlog.c's treatment of large WAL writes, and arguably also xlog.c and fd.c's treatment of EINTR. Arbitrary short returns for larger transfers have been observed on several OSes, and might in theory also happen for transient reasons with our own pg_p*v() fallback code. * After unexpected EOF or -1, the error thrown now talks about a range even for the single block case, eg "blocks 42..42". Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6ut5tum2g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4908c5872059c409aa647bcde758dfeffe07996e Modified Files -- doc/src/sgml/monitoring.sgml| 4 +- src/backend/storage/smgr/md.c | 325 src/backend/storage/smgr/smgr.c | 37 ++--- src/include/storage/md.h| 9 +- src/include/storage/smgr.h | 25 +++- 5 files changed, 279 insertions(+), 121 deletions(-)
pgsql: Provide multi-block smgrprefetch().
Provide multi-block smgrprefetch(). Previously smgrprefetch() could issue POSIX_FADV_WILLNEED advice for a single block at a time. Add an nblocks argument so that we can do the same for a range of blocks. This usually produces a single system call, but might need to loop if it crosses a segment boundary. Initially it is only called with nblocks == 1, but proposed patches will make wider calls. Reviewed-by: Heikki Linnakangas (earlier version) Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6ut5tum2g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b485ad7f07c80efbfd47329f138f0fe3a5acf013 Modified Files -- src/backend/storage/buffer/bufmgr.c | 2 +- src/backend/storage/buffer/localbuf.c | 2 +- src/backend/storage/smgr/md.c | 37 +-- src/backend/storage/smgr/smgr.c | 7 --- src/include/storage/md.h | 2 +- src/include/storage/smgr.h| 2 +- 6 files changed, 35 insertions(+), 17 deletions(-)
pgsql: Provide vectored variants of FileRead() and FileWrite().
Provide vectored variants of FileRead() and FileWrite(). FileReadV() and FileWriteV() adapt pg_preadv() and pg_pwritev() for fd.c's virtual file descriptors. The simple FileRead() and FileWrite() functions are now implemented in terms of the vectored functions, to avoid code duplication, and they are converted back to the corresponding simple system calls further down (commit 15c9ac36). Later work will make more interesting multi-iovec calls. The traditional behavior of reporting a "fake" ENOSPC error is simplified. It's now always set for non-failing writes, for the benefit of callers that expect to log a meaningful "%m" if they determine that the write was short. (Perhaps we should consider getting rid of that expectation one day.) Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6ut5tum2g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/871fe4917e1e92304bdcc2ab779de7416492c6de Modified Files -- src/backend/storage/file/fd.c | 43 +-- src/include/storage/fd.h | 32 +--- 2 files changed, 54 insertions(+), 21 deletions(-)
pgsql: Provide helper for retrying partial vectored I/O.
Provide helper for retrying partial vectored I/O. compute_remaining_iovec() is a re-usable routine for retrying after pg_readv() or pg_writev() reports a short transfer. This will gain new users in a later commit, but can already replace the open-coded equivalent code in the existing pg_pwritev_with_retry() function. Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6ut5tum2g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0c6be59f5e34f44b20d9ec3ffb58c1d9a0bf985e Modified Files -- src/common/file_utils.c | 77 - src/include/common/file_utils.h | 5 +++ 2 files changed, 57 insertions(+), 25 deletions(-)
pgsql: Define unconstify() and unvolatize() for C++.
Define unconstify() and unvolatize() for C++. These two macros wouldn't work if used in an inline function definition in a header seen by g++, because __builtin_types_compatible_p is only available in C. Redirect to standard C++ const_cast (which also adds/removes volatile despite its name). Per cpluspluscheck failure in a development branch. Suggested-by: Peter Eisentraut Discussion: https://postgr.es/m/CA%2BhUKGK3OXFjkOyZiw-DgL2bUqk9by1uGuCnViJX786W%2BfyDSw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/baf7c93ed583949d837bc13f24a15a0efbcb1ae7 Modified Files -- src/include/c.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Fix potential pointer overflow in xlogreader.c.
Fix potential pointer overflow in xlogreader.c. While checking if a record could fit in the circular WAL decoding buffer, the coding from commit 3f1ce973 used arithmetic that could overflow. 64 bit systems were unaffected for various technical reasons, which probably explains the lack of problem reports. Likewise for 32 bit systems running known 32 bit kernels. The systems at risk of problems appear to be 32 bit processes running on 64 bit kernels, with unlucky placement in memory. Per complaint from GCC -fsanitize=undefined -m32, while testing variations of 039_end_of_wal.pl. Back-patch to 15. Reviewed-by: Nathan Bossart Reviewed-by: Robert Haas Discussion: https://postgr.es/m/CA%2BhUKGKH0oRPOX7DhiQ_b51sM8HqcPp2J3WA-Oen%3DdXog%2BAGGQ%40mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b9f687f5abaf40c13fed59fe08014116a8344102 Modified Files -- src/backend/access/transam/xlogreader.c | 46 ++--- 1 file changed, 37 insertions(+), 9 deletions(-)
pgsql: Fix potential pointer overflow in xlogreader.c.
Fix potential pointer overflow in xlogreader.c. While checking if a record could fit in the circular WAL decoding buffer, the coding from commit 3f1ce973 used arithmetic that could overflow. 64 bit systems were unaffected for various technical reasons, which probably explains the lack of problem reports. Likewise for 32 bit systems running known 32 bit kernels. The systems at risk of problems appear to be 32 bit processes running on 64 bit kernels, with unlucky placement in memory. Per complaint from GCC -fsanitize=undefined -m32, while testing variations of 039_end_of_wal.pl. Back-patch to 15. Reviewed-by: Nathan Bossart Reviewed-by: Robert Haas Discussion: https://postgr.es/m/CA%2BhUKGKH0oRPOX7DhiQ_b51sM8HqcPp2J3WA-Oen%3DdXog%2BAGGQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cd7f19da34684b7b12fdc08511c5ce7bebb09419 Modified Files -- src/backend/access/transam/xlogreader.c | 46 ++--- 1 file changed, 37 insertions(+), 9 deletions(-)
pgsql: Fix potential pointer overflow in xlogreader.c.
Fix potential pointer overflow in xlogreader.c. While checking if a record could fit in the circular WAL decoding buffer, the coding from commit 3f1ce973 used arithmetic that could overflow. 64 bit systems were unaffected for various technical reasons, which probably explains the lack of problem reports. Likewise for 32 bit systems running known 32 bit kernels. The systems at risk of problems appear to be 32 bit processes running on 64 bit kernels, with unlucky placement in memory. Per complaint from GCC -fsanitize=undefined -m32, while testing variations of 039_end_of_wal.pl. Back-patch to 15. Reviewed-by: Nathan Bossart Reviewed-by: Robert Haas Discussion: https://postgr.es/m/CA%2BhUKGKH0oRPOX7DhiQ_b51sM8HqcPp2J3WA-Oen%3DdXog%2BAGGQ%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8ca56620caffd6a1761eebd6a9498235321f222b Modified Files -- src/backend/access/transam/xlogreader.c | 46 ++--- 1 file changed, 37 insertions(+), 9 deletions(-)
pgsql: Adjust obsolete comment explaining set_stack_base().
Adjust obsolete comment explaining set_stack_base(). Commit 7389aad6 removed the notion of backends started from inside a signal handler. A stray comment still referred to them, while explaining the need for a call to set_stack_base(). That leads to the question of whether we still need the call in !EXEC_BACKEND builds. There doesn't seem to be much point in suppressing it now, as it doesn't hurt and probably helps to measure the stack base from the exact same place in EXEC_BACKEND and !EXEC_BACKEND builds. Back-patch to 16. Reported-by: Heikki Linnakangas Reported-by: Tristan Partin Reported-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKG%2BEJHcevNGNOxVWxTNFbuB%3Dvjf4U68%2B85rAC_Sxvy2zEQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3b51265ee30784880fb2652051a4066ab9f9f90e Modified Files -- src/backend/utils/init/miscinit.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
pgsql: Adjust obsolete comment explaining set_stack_base().
Adjust obsolete comment explaining set_stack_base(). Commit 7389aad6 removed the notion of backends started from inside a signal handler. A stray comment still referred to them, while explaining the need for a call to set_stack_base(). That leads to the question of whether we still need the call in !EXEC_BACKEND builds. There doesn't seem to be much point in suppressing it now, as it doesn't hurt and probably helps to measure the stack base from the exact same place in EXEC_BACKEND and !EXEC_BACKEND builds. Back-patch to 16. Reported-by: Heikki Linnakangas Reported-by: Tristan Partin Reported-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKG%2BEJHcevNGNOxVWxTNFbuB%3Dvjf4U68%2B85rAC_Sxvy2zEQ%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cf84755575d1052770e92d291d1427720c8b53ca Modified Files -- src/backend/utils/init/miscinit.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
pgsql: Optimize pg_readv/pg_pwritev single vector case.
Optimize pg_readv/pg_pwritev single vector case. For the trivial case of iovcnt == 1, kernels are measurably slower at dealing with the more complex arguments of preadv/pwritev than the equivalent plain old pread/pwrite. The overheads are worth it for iovcnt > 1, but for 1 let's just redirect to the cheaper calls. While we could leave it to callers to worry about that, we already have to have our own pg_ wrappers for portability reasons so it seems reasonable to centralize this knowledge there (thanks to Heikki for this suggestion). Try to avoid function call overheads by making them inlinable, which might also allow the compiler to avoid the branch in some cases. For systems that don't have preadv and pwritev (currently: Windows and [closed] Solaris), we might as well pull the replacement functions up into the static inline functions too. Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6ut5tum2g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/15c9ac3629936a9bb5010155d3656e913027ccb7 Modified Files -- configure | 22 + configure.ac| 6 ++-- src/include/port/pg_iovec.h | 76 - src/port/meson.build| 2 -- src/port/preadv.c | 43 - src/port/pwritev.c | 43 - src/tools/msvc/Mkvcbuild.pm | 2 +- 7 files changed, 74 insertions(+), 120 deletions(-)
pgsql: Fix whitespace.
Fix whitespace. Use tabs instead of spaces for new paragraph, like existing paragraphs. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6631363a5992a81d7bbcecaba68886564ad701ba Modified Files -- src/port/pqsignal.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-)
pgsql: Improve comments about pqsignal().
Improve comments about pqsignal(). Explain where pqsignal() came from, what problem it originally solved without assuming the reader is familiar with historical Unixen, why we still need it, what it does for us now, and the key differences in frontend code on Windows. Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/CA%2BhUKG%2BRst1h3uo%2BXRgdRVnWHBa4mmj5gFbmCzZr73s-Fh_5JA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/262454be9a62d69d7523c0c88c7d07d5971a0fa0 Modified Files -- src/port/pqsignal.c | 34 ++ 1 file changed, 26 insertions(+), 8 deletions(-)
pgsql: jit: Adjust back-patch of f90b4a84 to 12 and 13.
jit: Adjust back-patch of f90b4a84 to 12 and 13. While back-patching f90b4a84, I missed that branches before REL_14_STABLE did some (accidental?) type punning in a function parameter, and failed to adjust these two branches accordingly. That didn't seem to cause a problem for newer LLVM versions or non-debug builds, but older debug builds would fail a type cross-check assertion. Fix by supplying the correct function argument type. In REL_14_STABLE the same change was made by commit df99ddc7. Per build farm animal xenodermus, which runs a debug build of LLVM 6 with jit_above_cost=0. Discussion: https://postgr.es/m/CA%2BhUKGLQ38rgZ3bvNHXPRjsWFAg3pa%3Dtnpeq0osa%2B%3DmiFD5jAw%40mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9ad98627614bfd603654e1a57c386a84b8834dc5 Modified Files -- src/backend/jit/llvm/llvmjit_expr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: jit: Adjust back-patch of f90b4a84 to 12 and 13.
jit: Adjust back-patch of f90b4a84 to 12 and 13. While back-patching f90b4a84, I missed that branches before REL_14_STABLE did some (accidental?) type punning in a function parameter, and failed to adjust these two branches accordingly. That didn't seem to cause a problem for newer LLVM versions or non-debug builds, but older debug builds would fail a type cross-check assertion. Fix by supplying the correct function argument type. In REL_14_STABLE the same change was made by commit df99ddc7. Per build farm animal xenodermus, which runs a debug build of LLVM 6 with jit_above_cost=0. Discussion: https://postgr.es/m/CA%2BhUKGLQ38rgZ3bvNHXPRjsWFAg3pa%3Dtnpeq0osa%2B%3DmiFD5jAw%40mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7c070e224c4abbe73eec6bb2917200379c9f8166 Modified Files -- src/backend/jit/llvm/llvmjit_expr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Log LLVM library version in configure output.
Log LLVM library version in configure output. When scanning build farm results, it's useful to be able to see which version is in use. For the Meson build system, this information was already displayed. Back-patch to all supported branches. Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0a6e2c7f86940f6d7c18c5dc2c50bf5f7ed3654d Modified Files -- config/llvm.m4 | 1 + configure | 2 ++ 2 files changed, 3 insertions(+)
pgsql: Log LLVM library version in configure output.
Log LLVM library version in configure output. When scanning build farm results, it's useful to be able to see which version is in use. For the Meson build system, this information was already displayed. Back-patch to all supported branches. Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/527e62a5e5d7037780e154159c76cb3f38716c87 Modified Files -- config/llvm.m4 | 1 + configure | 2 ++ 2 files changed, 3 insertions(+)
pgsql: Log LLVM library version in configure output.
Log LLVM library version in configure output. When scanning build farm results, it's useful to be able to see which version is in use. For the Meson build system, this information was already displayed. Back-patch to all supported branches. Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a13b63c788a30a49676ddee5ce3ab2bcd1c811d1 Modified Files -- config/llvm.m4 | 1 + configure | 2 ++ 2 files changed, 3 insertions(+)
pgsql: Log LLVM library version in configure output.
Log LLVM library version in configure output. When scanning build farm results, it's useful to be able to see which version is in use. For the Meson build system, this information was already displayed. Back-patch to all supported branches. Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/03e749c2b89e880e0a226458e9446fca4440696f Modified Files -- config/llvm.m4 | 1 + configure | 2 ++ 2 files changed, 3 insertions(+)
pgsql: Log LLVM library version in configure output.
Log LLVM library version in configure output. When scanning build farm results, it's useful to be able to see which version is in use. For the Meson build system, this information was already displayed. Back-patch to all supported branches. Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0e49e23782c55237f54aa60ed7a2b755b47cd4a2 Modified Files -- config/llvm.m4 | 1 + configure | 2 ++ 2 files changed, 3 insertions(+)
pgsql: Log LLVM library version in configure output.
Log LLVM library version in configure output. When scanning build farm results, it's useful to be able to see which version is in use. For the Meson build system, this information was already displayed. Back-patch to all supported branches. Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3b0f20f6ce145b0cd5aefa147a7e425b60601a58 Modified Files -- config/llvm.m4 | 1 + configure | 2 ++ 2 files changed, 3 insertions(+)
pgsql: Log LLVM library version in configure output.
Log LLVM library version in configure output. When scanning build farm results, it's useful to be able to see which version is in use. For the Meson build system, this information was already displayed. Back-patch to all supported branches. Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5e4dacb9878cf71e32950e90993afd9450dab4da Modified Files -- config/llvm.m4 | 1 + configure | 2 ++ 2 files changed, 3 insertions(+)
pgsql: Fix min_dynamic_shared_memory on Windows.
Fix min_dynamic_shared_memory on Windows. When min_dynamic_shared_memory is set above 0, we try to find space in a pre-allocated region of the main shared memory area instead of calling dsm_impl_XXX() routines to allocate more. The dsm_pin_segment() and dsm_unpin_segment() routines had a bug: they called dsm_impl_XXX() routines even for main region segments. Nobody noticed before now because those routines do nothing on Unix, but on Windows they'd fail while attempting to duplicate an invalid Windows HANDLE. Add the missing gating. Back-patch to 14, where commit 84b1c63a added this feature. Fixes pgsql-bugs bug #18165. Reported-by: Maxime Boyer Tested-by: Alexander Lakhin Discussion: https://postgr.es/m/18165-bf4f525cea6e51de%40postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fb9a16a1a6f24f5bbf05ca7a49bd4305575cc2f2 Modified Files -- src/backend/storage/ipc/dsm.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Fix min_dynamic_shared_memory on Windows.
Fix min_dynamic_shared_memory on Windows. When min_dynamic_shared_memory is set above 0, we try to find space in a pre-allocated region of the main shared memory area instead of calling dsm_impl_XXX() routines to allocate more. The dsm_pin_segment() and dsm_unpin_segment() routines had a bug: they called dsm_impl_XXX() routines even for main region segments. Nobody noticed before now because those routines do nothing on Unix, but on Windows they'd fail while attempting to duplicate an invalid Windows HANDLE. Add the missing gating. Back-patch to 14, where commit 84b1c63a added this feature. Fixes pgsql-bugs bug #18165. Reported-by: Maxime Boyer Tested-by: Alexander Lakhin Discussion: https://postgr.es/m/18165-bf4f525cea6e51de%40postgresql.org Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f72790b2952d75c885cf812b38d59d1586bf039e Modified Files -- src/backend/storage/ipc/dsm.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Fix min_dynamic_shared_memory on Windows.
Fix min_dynamic_shared_memory on Windows. When min_dynamic_shared_memory is set above 0, we try to find space in a pre-allocated region of the main shared memory area instead of calling dsm_impl_XXX() routines to allocate more. The dsm_pin_segment() and dsm_unpin_segment() routines had a bug: they called dsm_impl_XXX() routines even for main region segments. Nobody noticed before now because those routines do nothing on Unix, but on Windows they'd fail while attempting to duplicate an invalid Windows HANDLE. Add the missing gating. Back-patch to 14, where commit 84b1c63a added this feature. Fixes pgsql-bugs bug #18165. Reported-by: Maxime Boyer Tested-by: Alexander Lakhin Discussion: https://postgr.es/m/18165-bf4f525cea6e51de%40postgresql.org Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/174ccda5e2874fe33cc29b29dae753c1403288e3 Modified Files -- src/backend/storage/ipc/dsm.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Fix min_dynamic_shared_memory on Windows.
Fix min_dynamic_shared_memory on Windows. When min_dynamic_shared_memory is set above 0, we try to find space in a pre-allocated region of the main shared memory area instead of calling dsm_impl_XXX() routines to allocate more. The dsm_pin_segment() and dsm_unpin_segment() routines had a bug: they called dsm_impl_XXX() routines even for main region segments. Nobody noticed before now because those routines do nothing on Unix, but on Windows they'd fail while attempting to duplicate an invalid Windows HANDLE. Add the missing gating. Back-patch to 14, where commit 84b1c63a added this feature. Fixes pgsql-bugs bug #18165. Reported-by: Maxime Boyer Tested-by: Alexander Lakhin Discussion: https://postgr.es/m/18165-bf4f525cea6e51de%40postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dab889d60bac3fbf691973ca1770f2eb50547999 Modified Files -- src/backend/storage/ipc/dsm.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: jit: Changes for LLVM 17.
jit: Changes for LLVM 17. Changes required by https://llvm.org/docs/NewPassManager.html. Back-patch to 12, leaving the final release of 11 unchanged, consistent with earlier decision not to back-patch LLVM 16 support either. Author: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Andres Freund Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/CA%2BhUKG%2BWXznXCyTgCADd%3DHWkP9Qksa6chd7L%3DGCnZo-MBgg9Lg%40mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7da915e33abf54ce126d68baead4c1871b302c1c Modified Files -- src/backend/jit/llvm/llvmjit.c| 31 +++ src/backend/jit/llvm/llvmjit_wrap.cpp | 6 ++ 2 files changed, 37 insertions(+)
pgsql: jit: Changes for LLVM 17.
jit: Changes for LLVM 17. Changes required by https://llvm.org/docs/NewPassManager.html. Back-patch to 12, leaving the final release of 11 unchanged, consistent with earlier decision not to back-patch LLVM 16 support either. Author: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Andres Freund Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/CA%2BhUKG%2BWXznXCyTgCADd%3DHWkP9Qksa6chd7L%3DGCnZo-MBgg9Lg%40mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/53c4dabe18d3de365a96ccf8c7493a9ffd4b6dcf Modified Files -- src/backend/jit/llvm/llvmjit.c| 31 +++ src/backend/jit/llvm/llvmjit_wrap.cpp | 6 ++ 2 files changed, 37 insertions(+)
pgsql: jit: Changes for LLVM 17.
jit: Changes for LLVM 17. Changes required by https://llvm.org/docs/NewPassManager.html. Back-patch to 12, leaving the final release of 11 unchanged, consistent with earlier decision not to back-patch LLVM 16 support either. Author: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Andres Freund Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/CA%2BhUKG%2BWXznXCyTgCADd%3DHWkP9Qksa6chd7L%3DGCnZo-MBgg9Lg%40mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0a8b7d5c11266ba5291d0aafc0ff4f92ab1cc041 Modified Files -- src/backend/jit/llvm/llvmjit.c| 31 +++ src/backend/jit/llvm/llvmjit_wrap.cpp | 6 ++ 2 files changed, 37 insertions(+)
pgsql: jit: Changes for LLVM 17.
jit: Changes for LLVM 17. Changes required by https://llvm.org/docs/NewPassManager.html. Back-patch to 12, leaving the final release of 11 unchanged, consistent with earlier decision not to back-patch LLVM 16 support either. Author: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Andres Freund Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/CA%2BhUKG%2BWXznXCyTgCADd%3DHWkP9Qksa6chd7L%3DGCnZo-MBgg9Lg%40mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b60e3ac7603dfae3f810418b1fb5856d9fc7a328 Modified Files -- src/backend/jit/llvm/llvmjit.c| 31 +++ src/backend/jit/llvm/llvmjit_wrap.cpp | 6 ++ 2 files changed, 37 insertions(+)
pgsql: jit: Changes for LLVM 17.
jit: Changes for LLVM 17. Changes required by https://llvm.org/docs/NewPassManager.html. Back-patch to 12, leaving the final release of 11 unchanged, consistent with earlier decision not to back-patch LLVM 16 support either. Author: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Andres Freund Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/CA%2BhUKG%2BWXznXCyTgCADd%3DHWkP9Qksa6chd7L%3DGCnZo-MBgg9Lg%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/774185056834eef7702f6afb37731c583fa51a1a Modified Files -- src/backend/jit/llvm/llvmjit.c| 31 +++ src/backend/jit/llvm/llvmjit_wrap.cpp | 6 ++ 2 files changed, 37 insertions(+)
pgsql: jit: Changes for LLVM 17.
jit: Changes for LLVM 17. Changes required by https://llvm.org/docs/NewPassManager.html. Back-patch to 12, leaving the final release of 11 unchanged, consistent with earlier decision not to back-patch LLVM 16 support either. Author: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Andres Freund Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/CA%2BhUKG%2BWXznXCyTgCADd%3DHWkP9Qksa6chd7L%3DGCnZo-MBgg9Lg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/76200e5ee469e4a9db5f9514b9d0c6a31b496bff Modified Files -- src/backend/jit/llvm/llvmjit.c| 31 +++ src/backend/jit/llvm/llvmjit_wrap.cpp | 6 ++ 2 files changed, 37 insertions(+)
pgsql: jit: Supply LLVMGlobalGetValueType() for LLVM < 8.
jit: Supply LLVMGlobalGetValueType() for LLVM < 8. Commit 37d5babb used this C API function while adding support for LLVM 16 and opaque pointers, but it's not available in LLVM 7 and older. Provide it in our own llvmjit_wrap.cpp. It just calls a C++ function that pre-dates LLVM 3.9, our minimum target. Back-patch to 12, like 37d5babb. Discussion: https://postgr.es/m/CA%2BhUKGKnLnJnWrkr%3D4mSGhE5FuTK55FY15uULR7%3Dzzc%3DwX4Nqw%40mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d701f0d1f3e7ed9e8b8ff0d368add9cdae3b8108 Modified Files -- src/backend/jit/llvm/llvmjit_wrap.cpp | 8 src/include/jit/llvmjit.h | 4 2 files changed, 12 insertions(+)
pgsql: jit: Supply LLVMGlobalGetValueType() for LLVM < 8.
jit: Supply LLVMGlobalGetValueType() for LLVM < 8. Commit 37d5babb used this C API function while adding support for LLVM 16 and opaque pointers, but it's not available in LLVM 7 and older. Provide it in our own llvmjit_wrap.cpp. It just calls a C++ function that pre-dates LLVM 3.9, our minimum target. Back-patch to 12, like 37d5babb. Discussion: https://postgr.es/m/CA%2BhUKGKnLnJnWrkr%3D4mSGhE5FuTK55FY15uULR7%3Dzzc%3DwX4Nqw%40mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/981292c19f387c5416294096a22507a54ca30136 Modified Files -- src/backend/jit/llvm/llvmjit_wrap.cpp | 8 src/include/jit/llvmjit.h | 4 2 files changed, 12 insertions(+)
pgsql: jit: Supply LLVMGlobalGetValueType() for LLVM < 8.
jit: Supply LLVMGlobalGetValueType() for LLVM < 8. Commit 37d5babb used this C API function while adding support for LLVM 16 and opaque pointers, but it's not available in LLVM 7 and older. Provide it in our own llvmjit_wrap.cpp. It just calls a C++ function that pre-dates LLVM 3.9, our minimum target. Back-patch to 12, like 37d5babb. Discussion: https://postgr.es/m/CA%2BhUKGKnLnJnWrkr%3D4mSGhE5FuTK55FY15uULR7%3Dzzc%3DwX4Nqw%40mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ee3e4c41f35449c3cffc05a4b7738940075d9c28 Modified Files -- src/backend/jit/llvm/llvmjit_wrap.cpp | 8 src/include/jit/llvmjit.h | 4 2 files changed, 12 insertions(+)
pgsql: jit: Supply LLVMGlobalGetValueType() for LLVM < 8.
jit: Supply LLVMGlobalGetValueType() for LLVM < 8. Commit 37d5babb used this C API function while adding support for LLVM 16 and opaque pointers, but it's not available in LLVM 7 and older. Provide it in our own llvmjit_wrap.cpp. It just calls a C++ function that pre-dates LLVM 3.9, our minimum target. Back-patch to 12, like 37d5babb. Discussion: https://postgr.es/m/CA%2BhUKGKnLnJnWrkr%3D4mSGhE5FuTK55FY15uULR7%3Dzzc%3DwX4Nqw%40mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b2e0977886630b2bf749937fd694f0c3c1392210 Modified Files -- src/backend/jit/llvm/llvmjit_wrap.cpp | 8 src/include/jit/llvmjit.h | 4 2 files changed, 12 insertions(+)
pgsql: jit: Supply LLVMGlobalGetValueType() for LLVM < 8.
jit: Supply LLVMGlobalGetValueType() for LLVM < 8. Commit 37d5babb used this C API function while adding support for LLVM 16 and opaque pointers, but it's not available in LLVM 7 and older. Provide it in our own llvmjit_wrap.cpp. It just calls a C++ function that pre-dates LLVM 3.9, our minimum target. Back-patch to 12, like 37d5babb. Discussion: https://postgr.es/m/CA%2BhUKGKnLnJnWrkr%3D4mSGhE5FuTK55FY15uULR7%3Dzzc%3DwX4Nqw%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/60596f148a661e0fd1d7c1f13a72b55124511e3a Modified Files -- src/backend/jit/llvm/llvmjit_wrap.cpp | 8 src/include/jit/llvmjit.h | 4 2 files changed, 12 insertions(+)
pgsql: jit: Supply LLVMGlobalGetValueType() for LLVM < 8.
jit: Supply LLVMGlobalGetValueType() for LLVM < 8. Commit 37d5babb used this C API function while adding support for LLVM 16 and opaque pointers, but it's not available in LLVM 7 and older. Provide it in our own llvmjit_wrap.cpp. It just calls a C++ function that pre-dates LLVM 3.9, our minimum target. Back-patch to 12, like 37d5babb. Discussion: https://postgr.es/m/CA%2BhUKGKnLnJnWrkr%3D4mSGhE5FuTK55FY15uULR7%3Dzzc%3DwX4Nqw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f90b4a846b32d3d6d2fd9d55a93735501e4c34fd Modified Files -- src/backend/jit/llvm/llvmjit_wrap.cpp | 8 src/include/jit/llvmjit.h | 4 2 files changed, 12 insertions(+)
pgsql: jit: Support opaque pointers in LLVM 16.
jit: Support opaque pointers in LLVM 16. Remove use of LLVMGetElementType() and provide the type of all pointers to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM versions[1]. * For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions. * For LLVM == 15, we'll continue to do the same, explicitly opting out of opaque pointer mode. * For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take the extra type argument. The difference is hidden behind some new IR emitting wrapper functions l_load(), l_gep(), l_call() etc. The change is mostly mechanical, except that at each site the correct type had to be provided. In some places we needed to do some extra work to get functions types, including some new wrappers for C++ APIs that are not yet exposed by in LLVM's C API, and some new "example" functions in llvmjit_types.c because it's no longer possible to start from the function pointer type and ask for the function type. Back-patch to 12, because it's a little tricker in 11 and we agreed not to put the latest LLVM support into the upcoming final release of 11. [1] https://llvm.org/docs/OpaquePointers.html Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Ronan Dunklau Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/15ddc9725eb73d97a16652c7c90d993302773544 Modified Files -- src/backend/jit/llvm/llvmjit.c| 193 +++--- src/backend/jit/llvm/llvmjit_deform.c | 119 + src/backend/jit/llvm/llvmjit_expr.c | 471 +++--- src/backend/jit/llvm/llvmjit_types.c | 27 +- src/backend/jit/llvm/llvmjit_wrap.cpp | 12 + src/include/jit/llvmjit.h | 20 +- src/include/jit/llvmjit_emit.h| 106 ++-- 7 files changed, 565 insertions(+), 383 deletions(-)
pgsql: jit: Support opaque pointers in LLVM 16.
jit: Support opaque pointers in LLVM 16. Remove use of LLVMGetElementType() and provide the type of all pointers to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM versions[1]. * For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions. * For LLVM == 15, we'll continue to do the same, explicitly opting out of opaque pointer mode. * For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take the extra type argument. The difference is hidden behind some new IR emitting wrapper functions l_load(), l_gep(), l_call() etc. The change is mostly mechanical, except that at each site the correct type had to be provided. In some places we needed to do some extra work to get functions types, including some new wrappers for C++ APIs that are not yet exposed by in LLVM's C API, and some new "example" functions in llvmjit_types.c because it's no longer possible to start from the function pointer type and ask for the function type. Back-patch to 12, because it's a little tricker in 11 and we agreed not to put the latest LLVM support into the upcoming final release of 11. [1] https://llvm.org/docs/OpaquePointers.html Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Ronan Dunklau Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f28956b239f19858e7c429d3065678ce79c5104b Modified Files -- src/backend/jit/llvm/llvmjit.c| 130 ++- src/backend/jit/llvm/llvmjit_deform.c | 119 +- src/backend/jit/llvm/llvmjit_expr.c | 400 -- src/backend/jit/llvm/llvmjit_types.c | 25 +++ src/backend/jit/llvm/llvmjit_wrap.cpp | 12 + src/include/jit/llvmjit.h | 7 + src/include/jit/llvmjit_emit.h| 106 ++--- 7 files changed, 502 insertions(+), 297 deletions(-)
pgsql: jit: Support opaque pointers in LLVM 16.
jit: Support opaque pointers in LLVM 16. Remove use of LLVMGetElementType() and provide the type of all pointers to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM versions[1]. * For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions. * For LLVM == 15, we'll continue to do the same, explicitly opting out of opaque pointer mode. * For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take the extra type argument. The difference is hidden behind some new IR emitting wrapper functions l_load(), l_gep(), l_call() etc. The change is mostly mechanical, except that at each site the correct type had to be provided. In some places we needed to do some extra work to get functions types, including some new wrappers for C++ APIs that are not yet exposed by in LLVM's C API, and some new "example" functions in llvmjit_types.c because it's no longer possible to start from the function pointer type and ask for the function type. Back-patch to 12, because it's a little tricker in 11 and we agreed not to put the latest LLVM support into the upcoming final release of 11. [1] https://llvm.org/docs/OpaquePointers.html Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Ronan Dunklau Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/82d9a782a29633a7d2c8c0785e4162a46f93d23b Modified Files -- src/backend/jit/llvm/llvmjit.c| 57 ++--- src/backend/jit/llvm/llvmjit_deform.c | 119 +- src/backend/jit/llvm/llvmjit_expr.c | 397 -- src/backend/jit/llvm/llvmjit_types.c | 39 +++- src/backend/jit/llvm/llvmjit_wrap.cpp | 12 + src/include/jit/llvmjit.h | 6 + src/include/jit/llvmjit_emit.h| 106 ++--- 7 files changed, 475 insertions(+), 261 deletions(-)
pgsql: jit: Support opaque pointers in LLVM 16.
jit: Support opaque pointers in LLVM 16. Remove use of LLVMGetElementType() and provide the type of all pointers to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM versions[1]. * For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions. * For LLVM == 15, we'll continue to do the same, explicitly opting out of opaque pointer mode. * For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take the extra type argument. The difference is hidden behind some new IR emitting wrapper functions l_load(), l_gep(), l_call() etc. The change is mostly mechanical, except that at each site the correct type had to be provided. In some places we needed to do some extra work to get functions types, including some new wrappers for C++ APIs that are not yet exposed by in LLVM's C API, and some new "example" functions in llvmjit_types.c because it's no longer possible to start from the function pointer type and ask for the function type. Back-patch to 12, because it's a little tricker in 11 and we agreed not to put the latest LLVM support into the upcoming final release of 11. [1] https://llvm.org/docs/OpaquePointers.html Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Ronan Dunklau Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eed1feb3fee1a558b67b04cbd709f31142f071d5 Modified Files -- src/backend/jit/llvm/llvmjit.c| 57 ++--- src/backend/jit/llvm/llvmjit_deform.c | 119 +- src/backend/jit/llvm/llvmjit_expr.c | 397 -- src/backend/jit/llvm/llvmjit_types.c | 39 +++- src/backend/jit/llvm/llvmjit_wrap.cpp | 12 + src/include/jit/llvmjit.h | 7 + src/include/jit/llvmjit_emit.h| 106 ++--- 7 files changed, 476 insertions(+), 261 deletions(-)
pgsql: jit: Support opaque pointers in LLVM 16.
jit: Support opaque pointers in LLVM 16. Remove use of LLVMGetElementType() and provide the type of all pointers to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM versions[1]. * For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions. * For LLVM == 15, we'll continue to do the same, explicitly opting out of opaque pointer mode. * For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take the extra type argument. The difference is hidden behind some new IR emitting wrapper functions l_load(), l_gep(), l_call() etc. The change is mostly mechanical, except that at each site the correct type had to be provided. In some places we needed to do some extra work to get functions types, including some new wrappers for C++ APIs that are not yet exposed by in LLVM's C API, and some new "example" functions in llvmjit_types.c because it's no longer possible to start from the function pointer type and ask for the function type. Back-patch to 12, because it's a little tricker in 11 and we agreed not to put the latest LLVM support into the upcoming final release of 11. [1] https://llvm.org/docs/OpaquePointers.html Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Ronan Dunklau Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/74d19ec096dfbda5782e62892de7e86a104f8265 Modified Files -- src/backend/jit/llvm/llvmjit.c| 57 ++--- src/backend/jit/llvm/llvmjit_deform.c | 119 +- src/backend/jit/llvm/llvmjit_expr.c | 401 -- src/backend/jit/llvm/llvmjit_types.c | 39 +++- src/backend/jit/llvm/llvmjit_wrap.cpp | 12 + src/backend/jit/llvm/meson.build | 2 +- src/include/jit/llvmjit.h | 7 + src/include/jit/llvmjit_emit.h| 106 ++--- 8 files changed, 479 insertions(+), 264 deletions(-)
pgsql: jit: Support opaque pointers in LLVM 16.
jit: Support opaque pointers in LLVM 16. Remove use of LLVMGetElementType() and provide the type of all pointers to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM versions[1]. * For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions. * For LLVM == 15, we'll continue to do the same, explicitly opting out of opaque pointer mode. * For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take the extra type argument. The difference is hidden behind some new IR emitting wrapper functions l_load(), l_gep(), l_call() etc. The change is mostly mechanical, except that at each site the correct type had to be provided. In some places we needed to do some extra work to get functions types, including some new wrappers for C++ APIs that are not yet exposed by in LLVM's C API, and some new "example" functions in llvmjit_types.c because it's no longer possible to start from the function pointer type and ask for the function type. Back-patch to 12, because it's a little tricker in 11 and we agreed not to put the latest LLVM support into the upcoming final release of 11. [1] https://llvm.org/docs/OpaquePointers.html Reviewed-by: Dmitry Dolgov <9erthali...@gmail.com> Reviewed-by: Ronan Dunklau Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/37d5babb5cfa4c6795b3cb6de964ba019d3d60ab Modified Files -- src/backend/jit/llvm/llvmjit.c| 59 ++--- src/backend/jit/llvm/llvmjit_deform.c | 119 +- src/backend/jit/llvm/llvmjit_expr.c | 401 -- src/backend/jit/llvm/llvmjit_types.c | 39 +++- src/backend/jit/llvm/llvmjit_wrap.cpp | 12 + src/backend/jit/llvm/meson.build | 2 +- src/include/jit/llvmjit.h | 7 + src/include/jit/llvmjit_emit.h| 106 ++--- 8 files changed, 481 insertions(+), 264 deletions(-)
pgsql: Try to handle torn reads of pg_control in frontend.
Try to handle torn reads of pg_control in frontend. Some of our src/bin tools read the control file without any kind of interlocking against concurrent writes from the server. At least ext4 and ntfs can expose partially modified contents when you do that. For now, we'll try to tolerate this by retrying up to 10 times if the checksum doesn't match, until we get two reads in a row with the same bad checksum. This is not guaranteed to reach the right conclusion, but it seems very likely to. Thanks to Tom Lane for this suggestion. Various ideas for interlocking or atomicity were considered too complicated, unportable or expensive given the lack of field reports, but remain open for future reconsideration. Back-patch as far as 12. It doesn't seem like a good idea to put a heuristic change for a very rare problem into the final release of 11. Reviewed-by: Anton A. Melnikov Reviewed-by: David Steele Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/43c979086825e5df1816307fea9b41378cdc31bd Modified Files -- src/common/controldata_utils.c | 30 ++ 1 file changed, 30 insertions(+)
pgsql: Try to handle torn reads of pg_control in frontend.
Try to handle torn reads of pg_control in frontend. Some of our src/bin tools read the control file without any kind of interlocking against concurrent writes from the server. At least ext4 and ntfs can expose partially modified contents when you do that. For now, we'll try to tolerate this by retrying up to 10 times if the checksum doesn't match, until we get two reads in a row with the same bad checksum. This is not guaranteed to reach the right conclusion, but it seems very likely to. Thanks to Tom Lane for this suggestion. Various ideas for interlocking or atomicity were considered too complicated, unportable or expensive given the lack of field reports, but remain open for future reconsideration. Back-patch as far as 12. It doesn't seem like a good idea to put a heuristic change for a very rare problem into the final release of 11. Reviewed-by: Anton A. Melnikov Reviewed-by: David Steele Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/67060be3df34f451591f745ab942fe19addd385f Modified Files -- src/common/controldata_utils.c | 30 ++ 1 file changed, 30 insertions(+)
pgsql: Try to handle torn reads of pg_control in frontend.
Try to handle torn reads of pg_control in frontend. Some of our src/bin tools read the control file without any kind of interlocking against concurrent writes from the server. At least ext4 and ntfs can expose partially modified contents when you do that. For now, we'll try to tolerate this by retrying up to 10 times if the checksum doesn't match, until we get two reads in a row with the same bad checksum. This is not guaranteed to reach the right conclusion, but it seems very likely to. Thanks to Tom Lane for this suggestion. Various ideas for interlocking or atomicity were considered too complicated, unportable or expensive given the lack of field reports, but remain open for future reconsideration. Back-patch as far as 12. It doesn't seem like a good idea to put a heuristic change for a very rare problem into the final release of 11. Reviewed-by: Anton A. Melnikov Reviewed-by: David Steele Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dc75748a918e3ba0fccf0aeb090068e1f172b3e9 Modified Files -- src/common/controldata_utils.c | 30 ++ 1 file changed, 30 insertions(+)
pgsql: Try to handle torn reads of pg_control in frontend.
Try to handle torn reads of pg_control in frontend. Some of our src/bin tools read the control file without any kind of interlocking against concurrent writes from the server. At least ext4 and ntfs can expose partially modified contents when you do that. For now, we'll try to tolerate this by retrying up to 10 times if the checksum doesn't match, until we get two reads in a row with the same bad checksum. This is not guaranteed to reach the right conclusion, but it seems very likely to. Thanks to Tom Lane for this suggestion. Various ideas for interlocking or atomicity were considered too complicated, unportable or expensive given the lack of field reports, but remain open for future reconsideration. Back-patch as far as 12. It doesn't seem like a good idea to put a heuristic change for a very rare problem into the final release of 11. Reviewed-by: Anton A. Melnikov Reviewed-by: David Steele Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5e39884d322a7dd1dd595fbaaeb1f88c8907d3a6 Modified Files -- src/common/controldata_utils.c | 30 ++ 1 file changed, 30 insertions(+)
pgsql: Try to handle torn reads of pg_control in frontend.
Try to handle torn reads of pg_control in frontend. Some of our src/bin tools read the control file without any kind of interlocking against concurrent writes from the server. At least ext4 and ntfs can expose partially modified contents when you do that. For now, we'll try to tolerate this by retrying up to 10 times if the checksum doesn't match, until we get two reads in a row with the same bad checksum. This is not guaranteed to reach the right conclusion, but it seems very likely to. Thanks to Tom Lane for this suggestion. Various ideas for interlocking or atomicity were considered too complicated, unportable or expensive given the lack of field reports, but remain open for future reconsideration. Back-patch as far as 12. It doesn't seem like a good idea to put a heuristic change for a very rare problem into the final release of 11. Reviewed-by: Anton A. Melnikov Reviewed-by: David Steele Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5725e4ebe7a936f724f21e7ee1e84e54a70bfd83 Modified Files -- src/common/controldata_utils.c | 30 ++ 1 file changed, 30 insertions(+)
pgsql: Try to handle torn reads of pg_control in frontend.
Try to handle torn reads of pg_control in frontend. Some of our src/bin tools read the control file without any kind of interlocking against concurrent writes from the server. At least ext4 and ntfs can expose partially modified contents when you do that. For now, we'll try to tolerate this by retrying up to 10 times if the checksum doesn't match, until we get two reads in a row with the same bad checksum. This is not guaranteed to reach the right conclusion, but it seems very likely to. Thanks to Tom Lane for this suggestion. Various ideas for interlocking or atomicity were considered too complicated, unportable or expensive given the lack of field reports, but remain open for future reconsideration. Back-patch as far as 12. It doesn't seem like a good idea to put a heuristic change for a very rare problem into the final release of 11. Reviewed-by: Anton A. Melnikov Reviewed-by: David Steele Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/63a58c6b3db2b1103ddf67a04b31a8f8e9bb Modified Files -- src/common/controldata_utils.c | 30 ++ 1 file changed, 30 insertions(+)
Re: pgsql: Rename 005_login_trigger.pl to 006_login_trigger.pl
On Mon, Oct 16, 2023 at 2:04 PM Alexander Korotkov wrote: > Rename 005_login_trigger.pl to 006_login_trigger.pl > > In order to avoid numbering collision with 005_sspi.pl. Hi Alexander, Usually I notice if someone steals my TAP script number because there is git conflict in eg src/test/authentication/meson.build. Thinking abotu that, I noticed that your new test script is missing from there. The make scripts find the tests automatically, but for meson we now have to list them.
pgsql: Fix comment from commit 22655aa231.
Fix comment from commit 22655aa231. Per automated complaint from BF animal koel this needed to be re-indented, but there was also a typo. Back-patch to 16. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3090213690bd69dd46dae865a2021982e7309208 Modified Files -- src/backend/access/heap/heapam.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix comment from commit 22655aa231.
Fix comment from commit 22655aa231. Per automated complaint from BF animal koel this needed to be re-indented, but there was also a typo. Back-patch to 16. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/01529c7040088db2718628d0814058598152bd39 Modified Files -- src/backend/access/heap/heapam.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Acquire ControlFileLock in relevant SQL functions.
Acquire ControlFileLock in relevant SQL functions. Commit dc7d70ea added functions that read the control file, but didn't acquire ControlFileLock. With unlucky timing, file systems that have weak interlocking like ext4 and ntfs could expose partially overwritten contents, and the checksum would fail. Back-patch to all supported releases. Reviewed-by: David Steele Reviewed-by: Anton A. Melnikov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f1634c968101ebe48e5b7b8b274a9170669384ce Modified Files -- src/backend/utils/misc/pg_controldata.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Acquire ControlFileLock in relevant SQL functions.
Acquire ControlFileLock in relevant SQL functions. Commit dc7d70ea added functions that read the control file, but didn't acquire ControlFileLock. With unlucky timing, file systems that have weak interlocking like ext4 and ntfs could expose partially overwritten contents, and the checksum would fail. Back-patch to all supported releases. Reviewed-by: David Steele Reviewed-by: Anton A. Melnikov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/637e86ecc5e4fcc5447b67d83337bc8752a40a52 Modified Files -- src/backend/utils/misc/pg_controldata.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Acquire ControlFileLock in relevant SQL functions.
Acquire ControlFileLock in relevant SQL functions. Commit dc7d70ea added functions that read the control file, but didn't acquire ControlFileLock. With unlucky timing, file systems that have weak interlocking like ext4 and ntfs could expose partially overwritten contents, and the checksum would fail. Back-patch to all supported releases. Reviewed-by: David Steele Reviewed-by: Anton A. Melnikov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ae9da357bd6d3f553c9d2a148a97f4db35bc608d Modified Files -- src/backend/utils/misc/pg_controldata.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Acquire ControlFileLock in relevant SQL functions.
Acquire ControlFileLock in relevant SQL functions. Commit dc7d70ea added functions that read the control file, but didn't acquire ControlFileLock. With unlucky timing, file systems that have weak interlocking like ext4 and ntfs could expose partially overwritten contents, and the checksum would fail. Back-patch to all supported releases. Reviewed-by: David Steele Reviewed-by: Anton A. Melnikov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a56fe5cf07fea61f8d79570633298951697a3f72 Modified Files -- src/backend/utils/misc/pg_controldata.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Acquire ControlFileLock in relevant SQL functions.
Acquire ControlFileLock in relevant SQL functions. Commit dc7d70ea added functions that read the control file, but didn't acquire ControlFileLock. With unlucky timing, file systems that have weak interlocking like ext4 and ntfs could expose partially overwritten contents, and the checksum would fail. Back-patch to all supported releases. Reviewed-by: David Steele Reviewed-by: Anton A. Melnikov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/606be8a35d9726b6c0468428b6262e58d9e308af Modified Files -- src/backend/utils/misc/pg_controldata.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Acquire ControlFileLock in relevant SQL functions.
Acquire ControlFileLock in relevant SQL functions. Commit dc7d70ea added functions that read the control file, but didn't acquire ControlFileLock. With unlucky timing, file systems that have weak interlocking like ext4 and ntfs could expose partially overwritten contents, and the checksum would fail. Back-patch to all supported releases. Reviewed-by: David Steele Reviewed-by: Anton A. Melnikov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2371432cd6b93415ef99e7ef35598f4f85436163 Modified Files -- src/backend/utils/misc/pg_controldata.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Acquire ControlFileLock in relevant SQL functions.
Acquire ControlFileLock in relevant SQL functions. Commit dc7d70ea added functions that read the control file, but didn't acquire ControlFileLock. With unlucky timing, file systems that have weak interlocking like ext4 and ntfs could expose partially overwritten contents, and the checksum would fail. Back-patch to all supported releases. Reviewed-by: David Steele Reviewed-by: Anton A. Melnikov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c558e6fd92ffeb85d5f52e32ccbcf8a5b5eb7bf3 Modified Files -- src/backend/utils/misc/pg_controldata.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Add wait events for checkpoint delay mechanism.
Add wait events for checkpoint delay mechanism. When MyProc->delayChkptFlags is set to temporarily block phase transitions in a concurrent checkpoint, the checkpointer enters a sleep-poll loop to wait for the flag to be cleared. We should show that as a wait event in the pg_stat_activity view. Reviewed-by: Robert Haas Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CA%2BhUKGL7Whi8iwKbzkbn_1fixH3Yy8aAPz7mfq6Hpj7FeJrKMg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0013ba290b6684d095d93517ff2ca1fadf79bdb9 Modified Files -- src/backend/access/transam/xlog.c | 4 src/backend/utils/activity/wait_event_names.txt | 2 ++ 2 files changed, 6 insertions(+)
