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
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 Sat, Mar 23, 2024 at 3:01 AM Nick Renders wrote:
> We now have a second machine with this issue: it is an Intel Mac mini running
> macOS Sonoma (14.4) and PostgreSQL 16.2.
> This one only has a single Data directory, so there are no multiple instances
> running.
BTW if you're running
On Thu, Apr 4, 2024 at 3:11 AM Nick Renders wrote:
> In the macOS Finder, when you show the Info (command+i) for an external drive
> (or any partition that is not the boot drive), there is a checkbox "Ignore
> ownership on this volume" in the Permissions section. I think it is by
> default
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 :-)
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...
>
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
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
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
--
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
On Sun, Mar 31, 2024 at 5:59 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Yeah, sorry, I'm a bit baffled about this situation myself. Yesterday
> I've opened a one-line PR fix that should address the issue, maybe this
> would help. In the meantime I've attached what did work for me as a
>
On Sun, Mar 31, 2024 at 9:59 AM Tom Lane wrote:
> Thomas Munro writes:
> > I was reminded of this thread by ambient security paranoia. As it
> > stands, we require 1.0.2 (but we very much hope that package
> > maintainers and others in control of builds don't decide to u
On Thu, Sep 7, 2023 at 11:44 PM Daniel Gustafsson wrote:
> > On 7 Sep 2023, at 13:30, Thomas Munro wrote:
> > I don't like the idea that our *next* release's library version
> > horizon is controlled by Red Hat's "ELS" phase.
>
> Agreed. If we instead
On Fri, Mar 22, 2024 at 7:15 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > For verification, I've modified the deform.outblock to call LLVMBuildRet
> > instead of LLVMBuildRetVoid and this seems to help -- inline and deform
> > stages are still performed as before, but nothing crashes. But
On Sat, Mar 30, 2024 at 12:34 PM Tomas Vondra
wrote:
> Hmmm. I admit I didn't think about the "always prefetch" flag too much,
> but I did imagine it'd only affect some places (e.g. BHS, but not for
> sequential scans). If it could be done by lowering the combine limit,
> that could work too - in
On Sat, Mar 30, 2024 at 12:40 PM Tomas Vondra
wrote:
> Sorry, I meant the prefetch (readahead) built into ZFS. I may be wrong
> but I don't think the regular RA (in linux kernel) works for ZFS, right?
Right, it separate page cache ("ARC") and prefetch settings:
On Sat, Mar 30, 2024 at 7:07 AM Christoph Berg wrote:
> Ubuntu in their infinite wisdom have switched to LLVM 18 as default
> for their upcoming 24.04 "noble" LTS release while Debian is still
> defaulting to 16. I'm now seeing LLVM crashes on the 4 architectures
> we support on noble.
>
> Should
On Sat, Mar 30, 2024 at 11:37 AM Bruce Momjian wrote:
> You might have seen reports today about a very complex exploit added to
> recent versions of liblzma. Fortunately, it was only enabled two months
> ago and has not been pushed to most stable operating systems like Debian
> and Ubuntu. The
On Sat, Mar 30, 2024 at 10:39 AM Thomas Munro wrote:
> On Sat, Mar 30, 2024 at 4:53 AM Tomas Vondra
> wrote:
> > ... Maybe there should be some flag to force
> > issuing fadvise even for sequential patterns, perhaps at the tablespace
> > level? ...
>
> Yeah, I'v
On Sat, Mar 30, 2024 at 4:53 AM Tomas Vondra
wrote:
> Two observations:
>
> * The combine limit seems to have negligible impact. There's no visible
> difference between combine_limit=8kB and 128kB.
>
> * Parallel queries seem to work about the same as master (especially for
> optimal cases, but
1 - 100 of 6095 matches
Mail list logo
