On Sun, May 19, 2024 at 7:00 AM Alexander Lakhin wrote:
> With blocknums[1], timing is changed, but the effect is not persistent.
> 10 query15 executions in a row, b7b0f3f27:
> 277.932 ms
> 281.805 ms
> 278.335 ms
> 281.565 ms
> 284.167 ms
> 283.171 ms
> 281.165 ms
> 281.615 ms
> 285.394 ms
>
On Sun, May 19, 2024 at 10:46 AM Ole Peder Brandtzæg
wrote:
> On Wed, May 15, 2024 at 07:20:09AM +0200, Peter Eisentraut wrote:
> > Yes, let's get that v3-0001 patch into PG17.
>
> Upon seeing this get committed in 4dd29b6833, I noticed that the docs
> still advertise the llvm-config-$version
040_pg_createsubscriber.pl seems to be failing occasionally on
culicidae near "--dry-run on node S". I couldn't immediately see why.
That animal is using EXEC_BACKEND and I also saw a one-off failure a
bit like that on my own local Linux + EXEC_BACKEND test run
(sorry I didn't keep the details
On Fri, May 17, 2024 at 4:46 PM Thomas Munro wrote:
> The specific problem here is that LocalProcessControlFile() runs in
> every launched child for EXEC_BACKEND builds. Windows uses
> EXEC_BACKEND, and Windows' NTFS file system is one of the two file
> systems known to this
On Mon, Mar 18, 2024 at 10:41 PM Heikki Linnakangas wrote:
> Committed, with some final cosmetic cleanups. Thanks everyone!
Nitpicking from UBSan with EXEC_BACKEND on Linux (line numbers may be
a bit off, from a branch of mine):
../src/backend/postmaster/launch_backend.c:772:2: runtime error:
On Sat, May 18, 2024 at 11:30 AM Thomas Munro wrote:
> Andres happened to have TPC-DS handy, and reproduced that regression
> in q15. We tried some stuff and figured out that it requires
> parallel_leader_participation=on, ie that this looks like some kind of
> parallel fairness a
On Sat, May 18, 2024 at 8:09 AM Thomas Munro wrote:
> On Sat, May 18, 2024 at 1:00 AM Alexander Lakhin wrote:
> > I decided to compare v17 vs v16 performance (as I did the last year [1])
> > and discovered that v17 loses to v16 in the pg_tpcds (s64da_tpcds)
> > benchmark,
On Sat, May 18, 2024 at 1:00 AM Alexander Lakhin wrote:
> I decided to compare v17 vs v16 performance (as I did the last year [1])
> and discovered that v17 loses to v16 in the pg_tpcds (s64da_tpcds)
> benchmark, query15 (and several others, but I focused on this one):
> Best pg-src-master--.*
The specific problem here is that LocalProcessControlFile() runs in
every launched child for EXEC_BACKEND builds. Windows uses
EXEC_BACKEND, and Windows' NTFS file system is one of the two file
systems known to this list to have the concurrent read/write data
mashing problem (the other being
On Tue, Apr 16, 2024 at 4:10 AM Robert Haas wrote:
> On Wed, Apr 10, 2024 at 9:55 PM Thomas Munro wrote:
> > To rescue my initdb --rel-segsize project[1] for v18, I will have a go
> > at making that dynamic. It looks like we don't actually need to
> > alloc
On Fri, May 17, 2024 at 3:17 AM Nazir Bilal Yavuz wrote:
> Actually, 32 bit builds are working but the Perl version needs to be
> updated to 'perl5.36-i386-linux-gnu' in .cirrus.tasks.yml. I changed
> 0001 with the working version of 32 bit builds [1] and the rest is the
> same. All tests pass
[2] https://cirrus-ci.com/task/5459439048720384
From c0a05c2929e03558c730b148bdeb5d301dbc4312 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu, 16 May 2024 14:10:09 +1200
Subject: [PATCH v4 1/3] XXX CI kludge: bullseye->bookworm
Temporarily removed 32 bit tests, as the CI image is not fully
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
On Thu, May 16, 2024 at 10:43 AM Thomas Munro wrote:
> Any chance you could test this version please Alexander?
Sorry, cancel that. v3 is not good. I assume it fixes the GSSAPI
thing and is superficially better, but it doesn't handle code that
calls twice in a row and ignores the first res
On Thu, May 16, 2024 at 9:46 AM Thomas Munro wrote:
> Alright, unless anyone has an objection or ideas for improvements, I'm
> going to go ahead and back-patch this slightly tidied up version
> everywhere.
Of course as soon as I wrote that I thought of a useful improvement
myself: as
On Wed, May 15, 2024 at 6:00 PM Alexander Lakhin wrote:
> 15.05.2024 01:26, Thomas Munro wrote:
> > OK, so we know what the problem is here. Here is the simplest
> > solution I know of for that problem. I have proposed this in the past
> > and received negative feedback
r
versions, and yeah I see that we went a long time after 7 without
touching it and nobody cared. Yeah, it would be nice to get rid of
it. Here's a patch. Meson didn't have that.
From 025f8b0106821b5b6f2ab7992da388404e3e406c Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Wed, 15 May 2024 15:
On Sun, May 12, 2024 at 10:11 PM Tatsuo Ishii wrote:
> > I am able to apply all your patches. I found that a similar thing
> > happened before [0] and I guess your case is similar. Adding Thomas to
> > CC, he may be able to help more.
>
> Ok. Thanks for the info.
This obviously fixed itself
On Tue, May 14, 2024 at 9:00 PM Alexander Lakhin wrote:
> 14.05.2024 03:38, Thomas Munro wrote:
> > I was beginning to suspect that lingering odour myself. I haven't
> > look at the GSS code but I was imagining that what we have here is
> > perhaps not unsent data dro
On Tue, May 14, 2024 at 8:17 AM Tom Lane wrote:
> I'm not sure whether we've got unsent data pending in the problematic
> condition, nor why it'd remain unsent if we do (shouldn't the backend
> consume it anyway?). But this has the right odor for an explanation.
>
> I'm pretty hesitant to touch
On Sat, May 11, 2024 at 5:00 PM Alexander Lakhin wrote:
> 11.05.2024 07:25, Thomas Munro wrote:
> > On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin
> > wrote:
> >> 11.05.2024 06:26, Thomas Munro wrote:
> >>> Perhaps a no-image, no-change registered buffer sh
On Mon, May 13, 2024 at 12:26 AM Andrew Dunstan wrote:
> Well, this is more or less where I came in back in about 2002 :-) I've been
> trying to help support it ever since, mainly motivated by stubborn
> persistence than anything else. Still, I agree that the lack of support for
> the 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
On Sat, May 11, 2024 at 1:14 PM Thomas Munro wrote:
> Either way, it seems like we'll need to skip that test on Windows if
> we want hamerkop to be green. That can probably be cribbed from
> collate.windows.win1252.sql into contrib/citext/sql/citext_utf8.sql's
> prelude... I just do
On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin wrote:
> 11.05.2024 06:26, Thomas Munro wrote:
> > Perhaps a no-image, no-change registered buffer should not be
> > including an image, even for XLR_CHECK_CONSISTENCY? It's actually
> > useless for consistency checking to
On Sat, May 11, 2024 at 3:57 AM Andres Freund wrote:
> On 2024-05-10 16:00:01 +0300, Alexander Lakhin wrote:
> > and discovered that XLogRecordAssemble() calculates CRC over a buffer,
> > that might be modified by another process.
>
> If, with "might", you mean that it's legitimate for that
For example, 'i'::citext = 'İ'::citext fails to be true.
It must now be using UTF-8 (unlike, say, Drongo) and non-C ctype,
given that the test isn't skipped. This isn't the first time that
we've noticed that Windows doesn't seem to know about İ→i (see [1]),
but I don't think anyone has explained
On Thu, May 9, 2024 at 4:04 PM Bruce Momjian wrote:
> I welcome feedback. For some reason it was an easier job than usual.
> 2024-01-25 [820b5af73] jit: Require at least LLVM 10.
> Require LLVM version 10 or later (Peter Eisentraut)
Peter reviewed, I authored, and I think you intend to list
On Thu, Dec 28, 2023 at 11:42 AM Tom Lane wrote:
> Thomas Munro writes:
> > In CommitTransaction() there is a stretch of code beginning s->state =
> > TRANS_COMMIT and ending s->state = TRANS_DEFAULT, from which we call
> > out to various subsystems' AtEOXact_XXX()
On Wed, May 8, 2024 at 6:54 AM Justin Pryzby wrote:
> On Tue, May 07, 2024 at 10:55:28AM +1200, Thomas Munro wrote:
> > https://github.com/openzfs/zfs/issues/11641
> >
> > I don't know enough to say anything useful about that but it certainly
> > smells similar.
On Tue, May 7, 2024 at 6:21 AM Justin Pryzby wrote:
> FWIW: both are running zfs-2.2.3 RPMs from zfsonlinux.org.
...
> Yes, they're running centos7 with the indicated kernels.
So far we've got:
* spurious EIO when opening a file (your previous report)
* hanging with CPU spinning (?) inside
On Thu, Feb 15, 2024 at 10:40 PM Anton Voloshin
wrote:
> On 19/01/2024 01:35, Thomas Munro wrote:
> > I don't yet have an opinion on the best way to
> > do it though. Would it be enough to add emit_message($node, 0) after
> > advance_out_of_record_splitting_zone()?
>
On Wed, May 1, 2024 at 2:51 PM David Rowley wrote:
> On Wed, 24 Apr 2024 at 14:32, David Rowley wrote:
> > I've attached a patch with a few typo fixes and what looks like an
> > incorrect type for max_ios. It's an int16 and I think it needs to be
> > an int. Doing "max_ios = Min(max_ios,
On Tue, Apr 30, 2024 at 7:17 AM Thomas Munro wrote:
> On Tue, Apr 30, 2024 at 6:47 AM Maksim Milyutin wrote:
> >> Should not we call at the end the StrategyFreeBuffer() function to add
> >> target buffer to freelist and not miss it after invalidation?
>
> > Pl
On Tue, Apr 30, 2024 at 6:47 AM Maksim Milyutin wrote:
>> Should not we call at the end the StrategyFreeBuffer() function to add
>> target buffer to freelist and not miss it after invalidation?
> Please take a look at this issue, current implementation of
> EvictUnpinnedBuffer() IMO is
t yet thought about it much.
The patches are POC-quality only and certainly have bugs/missed edge
cases/etc. Thoughts, better ideas, references to writing about this
problem space, etc, welcome.
From 63cb8f88fd65ef34536c7d4360b964ca5e6cf62d Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu, 25
On Fri, Apr 26, 2024 at 4:37 AM Riku Iki wrote:
> I am wondering if there were preallocation related changes in PG16, and if it
> is possible to disable preallocation in PostgreSQL 16?
I have no opinion on the btrfs details, but I was wondering if someone
might show up with a system that
Rebased over ca89db5f.
I looked into whether we could drop the "old pass manager" code
too[1]. Almost, but nope, even the C++ API lacks a way to set the
inline threshold before LLVM 16, so that would cause a regression.
Although we just hard-code the threshold to 512 with a comment that
sounds
On Tue, Apr 23, 2024 at 8:05 AM Robert Haas wrote:
> I reworked the test cases so that they don't (I think) rely on
> symlinks working as they do on normal platforms.
Cool.
(It will remain a mystery for now why perl readlink() can't read the
junction points that PostgreSQL creates (IIUC), but
On Mon, Apr 22, 2024 at 12:00 AM Alexander Lakhin wrote:
> From what I can see, the following condition (namely, -l):
> if ($path =~ /^pg_tblspc\/(\d+)$/ && -l "$backup_path/$path")
> {
> push @tsoids, $1;
> return 0;
>
I don't know how to fix 82023d47^ on Windows[1][2], but in case it's
useful, here's a small clue. I see that Perl's readlink() does in
fact know how to read "junction points" on Windows[3], so if that was
the only problem it might have been very close to working. One
difference is that our own
On Fri, Apr 19, 2024 at 10:36 AM Thomas Munro wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276535
>
> So perhaps it's time for me to undo what I did before... looking now.
It turned out that I still needed the previous work-around, but I was
too clever for my own boots
On Fri, Apr 19, 2024 at 4:00 PM Tom Lane wrote:
> Thomas Munro writes:
> > Probably not this thread's fault, but following the breadcrumbs to the
> > last thread to touch the relevant test lines in
> > authentication/001_password, is it expected that we have these
> &
On Sat, Nov 18, 2023 at 7:46 AM Peter Eisentraut wrote:
> All done, thanks.
Probably not this thread's fault, but following the breadcrumbs to the
last thread to touch the relevant test lines in
authentication/001_password, is it expected that we have these
warnings?
psql::1: WARNING: roles
On Fri, Apr 19, 2024 at 6:01 AM Andres Freund wrote:
> On 2024-04-18 11:15:43 +, Sriram RK wrote:
> > We (IBM-AIX team) looked into this issue
> >
> > https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
> >
> > This is related to the compiler issue. The compilers
On Thu, Feb 8, 2024 at 3:53 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Tue, Jan 30, 2024 at 5:06 PM Tom Lane wrote:
> >> Thomas Munro writes:
> >>> Ahh, there is one: https://github.com/cpan-authors/IO-Tty/issues/38
>
> >> Just for the archives'
On Fri, Apr 19, 2024 at 12:57 AM Marcel Hofstetter
wrote:
> SKIP_READLINE_TESTS works. margay is now green again.
Great! FTR there was a third thing revealed by margay since you
enabled the TAP tests: commit e2a23576.
I would guess that the best chance of getting the readline stuff to
actually
On Thu, Apr 18, 2024 at 6:09 PM Japin Li wrote:
> /home/japin/postgres/build/../src/common/config_info.c:198:11: error:
> comparison of integer expressions of different signedness: 'int' and 'size_t'
> {aka 'long unsigned int'} [-Werror=sign-compare]
> 198 | Assert(i == *configdata_len);
On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut wrote:
> Maybe this means something like our int64 is long long int but the
> system's int64_t is long int underneath, but I don't see how that would
> matter for the limit macros.
Agreed, so I don't think it's long vs long long (when they have
On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut wrote:
> I'm not sure I understand the problem here. Do you mean that in theory
> a platform's PRId64 could be something other than "l" or "ll"?
Yes. I don't know why anyone would do that, and the systems I checked
all have the obvious
On Sat, Mar 23, 2024 at 3:23 PM Tom Lane wrote:
> Thomas Munro writes:
> > . o O ( int64_t, PRIdi64, etc were standardised a quarter of a century ago )
>
> Yeah. Now that we require C99 it's probably reasonable to assume
> that those things exist. I wouldn't be in favor
On Thu, Apr 18, 2024 at 1:40 AM Marcel Hofstetter
wrote:
> Using gnu tar helps to make pg_basebackup work.
Thanks! I guess that'll remain a mystery.
> It fails now at a later step.
Oh, this rings a bell:
[14:54:58] t/010_tab_completion.pl ..
Dubious, test returned 29 (wstat 7424, 0x1d00)
We
On Wed, Apr 17, 2024 at 7:17 PM Marcel Hofstetter
wrote:
> Is there a way to configure which tar to use?
>
> gnu tar would be available.
>
> -bash-5.1$ ls -l /usr/gnu/bin/tar
> -r-xr-xr-x 1 root bin 1226248 Jul 1 2022 /usr/gnu/bin/tar
Cool. I guess you could fix the test either by
Hi,
I noticed that margay (Solaris) has started running more of the tests
lately, but is failing in pg_basebaseup/010_pg_basebackup. It runs
successfully on wrasse (in older branches, Solaris 11.3 is desupported
in 17/master), and also on pollock (illumos, forked from common
ancestor Solaris 10
Hi,
I was grepping for iovec users and noticed that the shm_mq stuff
defines its own iovec struct. Is there any reason not to use the
standard one, now that we can? Will add to next commitfest.
From 20b44cab0bb9f6218270aa0ae150ac0e560b49fe Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Mon
On Mon, Jul 3, 2023 at 8:43 PM Heikki Linnakangas wrote:
> On 10/06/2023 05:23, Thomas Munro wrote:
> > 2. I don't like the way we have to deal with POSIX vs Windows at
> > every site where we use threads, and each place has a different style
> > of wrappers. I consi
On Sun, Apr 14, 2024 at 11:49 AM Tom Lane wrote:
> Dmitry Koterov writes:
> > I wish it was zsh... I tested it with zsh, but with bash (and with
> > low-level kill syscall), I observed the same effect unfortunately.
>
> > So it's still a puzzle.
>
> > 1. Even more, when I send a kill() low-level
On Sun, Apr 14, 2024 at 11:18 AM Dmitry Koterov
wrote:
> Can it be e.g. readline? Or something related to tty or session settings
> which psql could modify (I did not find any in the source code though).
I was wondering about that. Are you using libedit or libreadline?
What happens if you
On Wed, Jul 12, 2023 at 1:11 AM Dimitrios Apostolou wrote:
> So would it make sense for postgres to perform reads in bigger blocks? Is it
> easy-ish to implement (where would one look for that)? Or must the I/O unit be
> tied to postgres' page size?
FYI as of last week we can do a little bit of
On Tue, Mar 12, 2024 at 9:00 PM Alexander Lakhin wrote:
> I see two backends waiting:
> law 2420132 2420108 0 09:05 ?00:00:00 postgres: node: law
> postgres [local] DROP DATABASE waiting
> law 2420135 2420108 0 09:05 ?00:00:00 postgres: node: law
> postgres [local]
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.
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
--
On Wed, Apr 10, 2024 at 1:38 PM Thomas Munro wrote:
> Therefore, some time after the tree re-opens for hacking, we could rip
> out a bunch of support code for LLVM 10-13, and then rip out support
> for pre-opaque-pointer mode. Please see attached.
... or of course closer to the end of
On Thu, Apr 11, 2024 at 12:11 AM Robert Haas wrote:
> On Wed, Apr 10, 2024 at 6:21 AM Thomas Munro wrote:
> > Could we just write the blocks directly into the output array, and
> > then transpose them directly in place if start_blkno > 0? See
> > attached. I
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.
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
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
On Fri, Mar 8, 2024 at 6:53 AM Robert Haas wrote:
> ... We could
> avoid transposing relative block numbers to absolute block numbers
> whenever start_blkno is 0, ...
Could we just write the blocks directly into the output array, and
then transpose them directly in place if start_blkno > 0?
On Wed, Apr 10, 2024 at 5:03 PM Tom Lane wrote:
> I don't doubt that there are other clang versions where the problem
> bites a lot harder. What result do you get from the test I tried
> (turning mm_strdup into a no-op macro)?
#define mm_strdup(x) (x) does this:
Apple clang 15: master: 14s ->
On Wed, Apr 10, 2024 at 11:44 AM Tom Lane wrote:
> ... On my Mac laptop
> (Apple clang version 15.0.0), the compile time for preproc.o went from
> 6.7sec to 5.5sec.
Having seen multi-minute compile times on FreeBSD (where clang is the
system compiler) and Debian (where I get packages from
for LLVM 10-13, and then rip out support
for pre-opaque-pointer mode. Please see attached.
[1]
https://www.postgresql.org/message-id/CA%2BhUKG%2B-g61yq7Ce4aoZtBDO98b4GXH8Cu3zxVk-Zn1Vh7TKpA%40mail.gmail.com
From f5de5c6535b825033b1829eaf340baacc10ed654 Mon Sep 17 00:00:00 2001
From: Thomas Munro
On Tue, Apr 9, 2024 at 10:05 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> + /* In assertion builds, run the LLVM verify pass. */
> +#ifdef USE_ASSERT_CHECKING
> + LLVMPassBuilderOptionsSetVerifyEach(options, true);
> +#endif
Thanks, that seems
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
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
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
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
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
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
patch for the original issue, and a patch to try
that idea + a fix for that other complaint it spits out. The latter
would only run for LLVM 17+, but that seems OK.
From 57af42d9a1b47b7361c7200a17a210f2ca37bd5d Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Tue, 9 Apr 2024 18:10:30 +1200
Subject: [PA
On Tue, Apr 9, 2024 at 5:01 PM Michael Paquier wrote:
> On Mon, Apr 08, 2024 at 12:23:56PM +0300, Nazir Bilal Yavuz wrote:
> > On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
> >> As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
> >> is fixed already.
> >> Perhaps
id/flat/CA%2BhUKGK1in4FiWtisXZ%2BJo-cNSbWjmBcPww3w3DBM%2BwhJTABXA%40mail.gmail.com
From 7ee50aae3d4eba0df5bce05c196f411abb0bd9ab Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Mon, 8 Apr 2024 18:19:41 +1200
Subject: [PATCH v7 1/3] Use smgrwritev() for both overwriting and extending.
Since mdwrite() and mdext
781775e63277b370eb48ff Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Sat, 6 Apr 2024 13:28:28 +1300
Subject: [PATCH] Add READ_STREAM_OUT_OF_ORDER.
Just a proof-of-concept.
---
src/backend/storage/aio/read_stream.c | 42 +++
src/include/storage/read_stream.h |
mpiler understands __builtin_types_compatible_p. */
#undef HAVE__BUILTIN_TYPES_COMPATIBLE_P
--
2.44.0
From 0f1a87954e27cd6e59e3ef45b610677b13a3985b Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 5 Apr 2024 15:06:32 +1300
Subject: [PATCH 2/2] Prefetch page header memory when str
On Tue, Apr 9, 2024 at 7:47 AM Robert Haas wrote:
> - The streaming read API stuff was all committed very last minute. I
> think this should have been committed much sooner. It's probably not
> going to break the world; it's more likely to have performance
> consequences. But if it had gone in
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
On Mon, Apr 8, 2024 at 11:53 AM Melanie Plageman
wrote:
> I've reviewed v6. I think you should mention in the docs that it only
> works for shared buffers -- so specifically not buffers containing
> blocks of temp tables.
Thanks for looking! The whole pg_buffercache extension is for working
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
On Mon, Apr 8, 2024 at 12:10 PM Andres Freund wrote:
> On 2024-04-07 11:07:58 +1200, Thomas Munro wrote:
> > I thought of a better name for the bufmgr.c function though:
> > InvalidateUnpinnedBuffer(). That name seemed better to me after I
> > festooned it with warnings a
is not obvious that this code matches Knuth's
Algorithm S ..." and realised I'm not sure I have time to develop a
good opinion about this today. So I'll leave the 0002 change out for
now, as it's a tidy-up that can easily be applied in the next cycle.
From c3b8df8e4720d8b0dfb4c892c0aa3ddae
On Mon, Apr 8, 2024 at 10:26 AM Melanie Plageman
wrote:
> On Sun, Apr 07, 2024 at 03:00:00PM -0700, Andres Freund wrote:
> > > src/backend/commands/analyze.c | 89 ++
> > > 1 file changed, 26 insertions(+), 63 deletions(-)
> >
> > That's a very nice demonstration
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
On Sun, Apr 7, 2024 at 1:34 PM Melanie Plageman
wrote:
> Attached v13 0001 is your fix and 0002 is a new version of the
> sequential scan streaming read user. Off-list Andres mentioned that I
> really ought to separate the parallel and serial sequential scan users
> into two different callbacks.
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
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
fix
for that, longer explanation in commit message.
From 43cef2d58141ba048e9349b0027afff148be5553 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Sun, 7 Apr 2024 12:36:44 +1200
Subject: [PATCH] Fix bug in read_stream.c.
When we determine that a wanted block can't be combined with the current
pending read
2001
From: Thomas Munro
Date: Sun, 7 Apr 2024 09:13:17 +1200
Subject: [PATCH v6] Add pg_buffercache_invalidate() function for testing.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When testing buffer pool logic, it is useful to be able to evict
arbitr
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
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
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
On Sat, Apr 6, 2024 at 6:55 AM Alvaro Herrera wrote:
> Pushed 0001.
Could that be related to the 3 failures on parula that look like this?
TRAP: failed Assert("node->next == 0 && node->prev == 0"), File:
"../../../../src/include/storage/proclist.h", Line: 63, PID: 29119
2024-04-05 16:16:26.812
1 - 100 of 6130 matches
Mail list logo
