On Wed, Nov 29, 2023 at 1:17 AM Thomas Munro wrote:
> Done. I like it, I just feel a bit bad about moving the p*v()
> replacement functions around a couple of times already! I figured it
> might as well be static inline even if we use the fallback (= Solaris
> and Windows).
Just fo
On Thu, May 23, 2024 at 9:58 AM Martijn Wallet wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:not tested
>
> Hi, I
On Tue, May 21, 2024 at 9:11 AM Melanie Plageman
wrote:
> So, if you are seeing the slow-down mostly go away by reducing
> blocknums array size, does the regression only appear when the scan
> data is fully in shared buffers? Or is this blocknums other use
> (dealing with short reads)?
That must
On Mon, May 20, 2024 at 1:09 PM Tom Lane wrote:
> (The cfbot tends to discourage this, since as soon as one of the
> patches is committed it no longer knows how to apply the rest.
> Can we improve on that tooling somehow?)
Cfbot currently applies patches with (GNU) patch
--no-backup-if-mismatch
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
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
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
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 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 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
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
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
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
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
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.
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
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
On Sat, Apr 6, 2024 at 6:55 AM Melanie Plageman
wrote:
> On Fri, Apr 5, 2024 at 12:15 AM Thomas Munro wrote:
> > The interesting column is hot. The 200ms->211ms regression is due to
> > the extra bookkeeping in the slow path. The rejiggered fastpath code
> > fixes it fo
On Sun, Mar 31, 2024 at 12:49 PM Thomas Munro wrote:
> https://github.com/llvm/llvm-project/pull/87093
Oh, with those clues, I think I might see... It is a bit strange that
we copy attributes from AttributeTemplate(), a function that returns
Datum, to our void deform function. It works (I m
, going to find my Mac...
[1]
https://www.postgresql.org/message-id/flat/CAApHDvpTRx7hqFZGiZJ%3Dd9JN4h1tzJ2%3Dxt7bM-9XRmpVj63psQ%40mail.gmail.com
From 74b8cde45a8babcec7b52b06bdb8ea046a0a966f Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 5 Apr 2024 13:32:14 +1300
Subject: [PATCH v10 1/4]
Hi,
+command_ok(
+ [
+ 'initdb', '--no-sync',
+ '--locale-provider=builtin', '-E UTF-8',
+ '--builtin-locale=C.UTF-8', "$tempdir/data8"
+ ],
+ 'locale provider builtin with -E UTF-8 --builtin-locale=C.UTF-8');
This Sun animal recently
On Fri, Apr 5, 2024 at 4:20 AM Melanie Plageman
wrote:
> So, sequential scan does not have per-buffer data. I did some logging
> and the reason most fully-in-SB sequential scans don't use the fast
> path is because read_stream->pending_read_nblocks is always 0.
Hnghghghgh... right, sorry I
On Thu, Apr 4, 2024 at 8:02 PM David Rowley wrote:
> 3a4a3537a
> latency average = 34.497 ms
> latency average = 34.538 ms
>
> 3a4a3537a + read_stream_for_seqscans.patch
> latency average = 40.923 ms
> latency average = 41.415 ms
>
> i.e. no meaningful change from the refactor, but a regression
On Thu, Apr 4, 2024 at 10:31 PM Thomas Munro wrote:
> Alright what about this?
Forgot to git add a change, new version.
From 6dea2983abf8d608c34e02351d70694de99f25f2 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu, 4 Apr 2024 20:31:26 +1300
Subject: [PATCH v2 1/2] Al
t about this?
From 6dea2983abf8d608c34e02351d70694de99f25f2 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu, 4 Apr 2024 20:31:26 +1300
Subject: [PATCH 1/2] Allow BufferAccessStrategy to limit pin count.
When pinning extra buffers to look ahead, users of a strategy are in
danger of pinning a lot of the b
d
them over relevant recent commits, so I could leave them in working
state in case anyone is interested in this file I/O-level stuff...
From c6d227678c586387a49c30c4f9a61f62c9b04b1c Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Wed, 13 Mar 2024 17:02:42 +1300
Subject: [PATCH v5 1/3] Prov
On Fri, Mar 8, 2024 at 6:20 AM Maxim Orlov wrote:
> Quite an interesting patch, in my opinion. I've decided to work on it a bit,
> did some refactoring (sorry) and add
> basic tests. Also, I try to take into account as much as possible notes on
> the patch, mentioned by Cédric Villemain.
On Thu, Apr 4, 2024 at 11:51 AM Peter Eisentraut wrote:
> On 30.03.24 22:27, Thomas Munro wrote:
> > Hmm, OK so it doesn't have 3 available in parallel from base repos.
> > But it's also about to reach end of "full support" in 2 months[1], so
> > if we ap
On Thu, Apr 4, 2024 at 6:03 AM Melanie Plageman
wrote:
> On Tue, Apr 2, 2024 at 1:10 PM Heikki Linnakangas wrote:
> > On 01/04/2024 22:58, Melanie Plageman wrote:
> > > Attached v7 has version 14 of the streaming read API as well as a few
> > > small tweaks to comments and code.
> >
> > I saw
On Tue, Apr 2, 2024 at 9:39 PM Thomas Munro wrote:
> So this is the version I'm going to commit shortly, barring objections.
And done, after fixing a small snafu with smgr-only reads coming from
CreateAndCopyRelationData() (BM_PERMANENT would be
incorrectly/unnecessarily set for unlogged tab
On Wed, Mar 27, 2024 at 11:27 AM Wolfgang Walther
wrote:
> The animal runs in a docker container via GitHub Actions in [2].
Great idea :-)
a054f Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Tue, 2 Apr 2024 14:40:40 +1300
Subject: [PATCH v15 1/4] Provide vectored variant of ReadBuffer().
Break ReadBuffer() up into two steps: StartReadBuffers() and
WaitReadBuffers(). This has two main advantages:
1. Multiple consecutive block
On Tue, Apr 2, 2024 at 8:43 AM Tomas Vondra
wrote:
> And I think he's right, and my tests confirm this. I did a trivial patch
> to align the blocks to 8K boundary, by forcing the header to be a
> multiple of 8K (I think 4K alignment would be enough). See the 0001
> patch that does this.
>
> And
On Sun, Mar 31, 2024 at 5:33 PM Tomas Vondra
wrote:
> I'm on 2.2.2 (on Linux). But there's something wrong, because the
> pg_combinebackup that took ~150s on xfs/btrfs, takes ~900s on ZFS.
>
> I'm not sure it's a ZFS config issue, though, because it's not CPU or
> I/O bound, and I see this on
+wb = copy_file_range(s->fd, [i], wfd, NULL, BLCKSZ, 0);
Can you collect adjacent blocks in one multi-block call? And then I
think the contract is that you need to loop if it returns short.
On Sun, Mar 31, 2024 at 1:37 PM Tomas Vondra
wrote:
> So I decided to take a stab at Thomas' idea, i.e. reading the data to
> ...
> I'll see how this works on EXT4/ZFS next ...
Wow, very cool! A couple of very quick thoughts/notes:
ZFS: the open source version only gained per-file block
1 - 100 of 3747 matches
Mail list logo
