On Tue, Apr 8, 2025 at 7:48 AM Hannu Krosing wrote:
> Just to bring this out separately : Does anybody have any idea why pipe
> commands close inside tests ?
>
> Re: 003-pg_dump_basic_tests has a few basic validation tests for
> correctmflag combinations. We need to write more automated tests in
On Sat, Apr 26, 2025 at 5:43 AM Tom Lane wrote:
> Andres Freund writes:
> > It's kinda sad to not have any test that tests a larger
> > io_combine_limit/io_max_combine_limit - as evidenced by this bug that'd be
> > good. However, not all platforms have PG_IOV_MAX > 16, so it seems like it'd
> > b
On Mon, Apr 7, 2025 at 10:04 PM Heikki Linnakangas wrote:
> I'm surprised how big the difference is, because I actually expected the
> compiler to detect the memory-zeroing loop and replace it with some
> fancy vector instructions (does powerpc have any?).
It certainly does, and we've played with
On Mon, Apr 21, 2025 at 9:30 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Yeah, that would work and will allow to avoid MAP_FIXED and mremap, which are
> questionable from portability point of view. This leaves memfd_create, and I'm
> still not completely clear on it's portability -- it seems
On Thu, Nov 21, 2024 at 8:55 PM Peter Eisentraut wrote:
> On 19.11.24 14:29, Dmitry Dolgov wrote:
> >> I see that memfd_create() has a MFD_HUGETLB flag. It's not very clear how
> >> that interacts with the MAP_HUGETLB flag for mmap(). Do you need to
> >> specify
> >> both of them if you want hu
On Fri, Apr 18, 2025 at 9:17 PM Thomas Munro wrote:
> On Fri, Apr 18, 2025 at 7:25 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > Thanks for sharing. I need to do more thorough tests, but after a quick
> > look I'm not sure about that. ftruncate will take care
On Fri, Apr 18, 2025 at 7:25 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Thu, Apr 17, 2025 at 03:22:28PM GMT, Ashutosh Bapat wrote:
> >
> > In an offlist chat Thomas Munro mentioned that just ftruncate() would
> > be enough to resize the shared memory
On Fri, Apr 18, 2025 at 3:54 AM Thomas Munro wrote:
> I contemplated that once before, when I wrote a quick demo patch[1] to
> implement huge_pages=on for FreeBSD (ie explicit rather than
> transparent). I used a different function, not the Linuxoid one but
Oops, I forgot to supply th
On Thu, Apr 17, 2025 at 1:58 AM Thomas Munro wrote:
> I have no answers but I have speculated for years about a very
> specific case (without any idea where to begin due to lack of ... I
> guess all this sort of stuff): in ExecParallelHashJoinNewBatch(),
> workers split up and tr
On Wed, Apr 16, 2025 at 9:14 PM Jakub Wartak
wrote:
> 2. Should we also interleave DSA/DSM for Parallel Query? (I'm not an
> expert on DSA/DSM at all)
I have no answers but I have speculated for years about a very
specific case (without any idea where to begin due to lack of ... I
guess all this
On Tue, Apr 15, 2025 at 5:44 AM Robert Haas wrote:
> On Thu, Apr 10, 2025 at 11:15 PM Thomas Munro wrote:
> > The new streaming BHS isn't just issuing probabilistic hints about
> > future access obtained from a second iterator. It has just one shared
> > iterator c
tidbitmap.c's operations loop over all the bits, but could leap over
zeros with bitmap instructions like bitmapset.c. Hard to imagine that
matters, but I think it also comes out easier to read?
From 7eec670224270c098c2fb3ad4b7748b0769a1e95 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date
On Mon, Apr 14, 2025 at 5:45 AM Jose Luis Tallon
wrote:
> On 12/4/25 18:59, Thomas Munro wrote:
> > It's hard to know how to set io_workers=3.
>
> Hmmm enable the below behaviour if "io_workers=auto" (default) ?
Why not just delete io_workers? If you really wa
independent of this topic, and might
be potential cleanups/fixes for master/v18. The last is a simple
latency test.
Ideas, testing, flames etc welcome.
From 1dbba36f67df5d3d34a990613d6d68d15caf1b17 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Sat, 29 Mar 2025 13:25:27 +1300
Subject: [PATCH
On Tue, Apr 8, 2025 at 1:43 AM Andres Freund wrote:
> On 2025-04-07 16:03:48 +0300, Nazir Bilal Yavuz wrote:
> > On Wed, 5 Mar 2025 at 18:51, Andres Freund wrote:
> > > I'm inclined to think we should apply to this to all branches with CI
> > > support,
> > > not just master. It's kind of annoyi
On Fri, Apr 11, 2025 at 5:50 AM James Hunter wrote:
> I am looking at the pre-streaming code, in PG 17, as I am not familiar
> with the PG 18 "streaming" code. Back in PG 17, nodeBitmapHeapscan.c
> maintained two shared TBM iterators, for PQ. One of the iterators was
> the actual, "fetch" iterator
uld need.
*/
queue_overflow = io_combine_limit - 1;
The patch clearly lacks a comment to explain that mystery. Will add. Thanks!
> I think all these variables really ought to be unsigned. None of them ever
> could be negative afaict.
Maybe... I tend to default to signed
On Tue, Apr 8, 2025 at 2:20 PM Andres Freund wrote:
> In the attached I implemented the above idea, with some small additional
> refinements:
LGTM.
How I wish EXPLAIN would show some clues about strategies...
On Sun, Mar 30, 2025 at 6:24 AM Peter Eisentraut wrote:
> I have committed v2-0001, omitting the parts that I had flagged in my
> review. I have also committed v2-0002. From my perspective, this can
> conclude this thread.
Thank you! Fingers crossed that the translation updates go as
smoothly
On Wed, Mar 26, 2025 at 12:36 PM Tom Lane wrote:
> Daniel Gustafsson writes:
> >> On 26 Mar 2025, at 00:01, Tom Lane wrote:
> >> How did that work before? Perhaps somebody just now added a libpq
> >> dependency to pg_regress.c?
>
> > I believe the libpq dependency came in 66d6086cbcbfc8 which w
On Wed, Apr 9, 2025 at 1:46 PM James Hunter wrote:
> On Mon, Apr 7, 2025 at 7:34 PM Thomas Munro wrote:
> > On Thu, Feb 13, 2025 at 1:40 PM Melanie Plageman
> > wrote:
> > > Thomas mentioned this to me off-list, and I think he's right. We
> > > likely n
v18, but
it's why I used relblocknumber % 3 != 2 and not eg relblocknumber % 2
!= 1 above.
From 3b460cb102c8af49a0af0d3b08bf86a436564fd3 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Sat, 15 Feb 2025 14:47:25 +1300
Subject: [PATCH v2 1/4] Move read stream modulo arithmetic into functions
that was a long explanation for why I didn't come up with an
easy patch to teach PBHS not to destroy I/O combining opportunities
for v18 :-) The short version is that 0001 does address the immediate
problem we identified, but also helped me see the bigger picture a
little bit more clearly and find a few interest
On Wed, Mar 26, 2025 at 12:47 AM Nazir Bilal Yavuz wrote:
> Rebased version of the patch is attached.
I noticed that it wasn't working on a Mac I tested because
guc_tables.c needed to include and fixed that. I also
did some minor editig of the docs, mostly removing the mention of
specific file
On Mon, Apr 7, 2025 at 1:29 PM Andres Freund wrote:
> On 2025-04-03 14:43:40 +1300, Thomas Munro wrote:
> > On Thu, Apr 3, 2025 at 11:17 AM Andres Freund wrote:
> > > I don't actually see any reason for buffer_limit to be a 16bit quantity?
> > > It's
&
On Thu, Mar 20, 2025 at 2:38 AM Daniel Gustafsson wrote:
> > On 19 Mar 2025, at 05:57, Tom Lane wrote:
> >
> > BTW, I was pretty seriously disheartened just now to realize that
> > this feature was implemented by making libpq depend on libcurl.
> > I'd misread the relevant commit messages to say
On Thu, Mar 20, 2025 at 12:06 PM Andres Freund wrote:
> Ah - it effectively is already in a critical section, just a weirdly spelled
> one:
>
> 2025-03-19 19:00:06.398 EDT [2156613][client backend][0/3:0][psql] LOG:
> statement: DROP TABLE foo;
> 2025-03-19 19:00:06.404 EDT [2156613][client bac
On Thu, Apr 3, 2025 at 11:17 AM Andres Freund wrote:
> I don't actually see any reason for buffer_limit to be a 16bit quantity? It's
> just to clamp things down, right?
Ugh. It might be worth just flipping this whole thing over to ints,
let me look into that...
On Tue, Mar 18, 2025 at 5:56 AM Andres Freund wrote:
> So one thing is that the pin count differs by 1 at the start of the scan. No
> idea why.
>
> I still don't know what drives the difference between freebsd and the rest,
> but IIUC the reason this fails is just that we are holding too many buff
On Thu, Mar 27, 2025 at 10:41 AM Andres Freund wrote:
> > > Subject: [PATCH v2.12 13/28] Enable IO concurrency on all systems
> >
> > Consider also updating this comment to stop focusing on prefetch; I think
> > changing that aligns with the patch's other changes:
> >
> > /*
> > * How many buffer
On Wed, Mar 26, 2025 at 10:34 AM Nathan Bossart
wrote:
> anaconda seems to be upset about this one [0]. I've spent all of 30
> seconds looking at it so far, but it appears to be using an old version of
> the header file.
>
> In file included from pg_regress.c:34:
> /usr/local/include/libpq-fe.h:6
On Wed, Mar 5, 2025 at 6:00 AM Peter Eisentraut wrote:
> I agree with your patch 0001-Deprecate-pg_int64.patch. I don't see a
> reason to keep the current arrangement around pg_int64.
Thanks for looking! Pushed.
On Tue, Mar 25, 2025 at 2:18 PM Andres Freund wrote:
> Attached v2.12, with the following changes:
Here's a tiny fixup to make io_concurrency=0 turn on
READ_BUFFERS_SYNCHRONOUSLY as mooted in a FIXME. Without this, AIO
will still run at level 1 even if you asked for 0. Feel free to
squash, or i
On Tue, Mar 25, 2025 at 11:55 AM Andres Freund wrote:
> If a callback may sometimes need to block, it can still opt into
> READ_STREAM_USE_BATCHING, by submitting all staged IO before blocking.
>
> The hardest part is to explain the flag. Here's my current attempt:
>
> /* ---
> * Opt-in to using
On Mon, Mar 24, 2025 at 5:59 AM Andres Freund wrote:
> On 2025-03-23 08:55:29 -0700, Noah Misch wrote:
> > An IO in PGAIO_HS_STAGED clearly blocks closing the IO's FD, and an IO in
> > PGAIO_HS_COMPLETED_IO clearly doesn't block that close. For
> > io_method=worker,
> > closing in PGAIO_HS_SUBMI
On Thu, Mar 20, 2025 at 11:02 AM Thomas Munro wrote:
> On Thu, Mar 20, 2025 at 10:04 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > How feasible/fragile/weird would it be to dlopen() it on demand?
. o O { There may also be security reasons to reject the idea, would
need to look into that... }
On Thu, Mar 20, 2025 at 11:19 AM Tom Lane wrote:
> Thomas Munro writes:
> > It would increase the build dependencies, assuming a package
> > maintainer wants to enable as many features as possible, but it would
> > *not* increase the 'package requires' footprint, m
On Thu, Mar 20, 2025 at 10:04 AM Tom Lane wrote:
> Thomas Munro writes:
> > How feasible/fragile/weird would it be to dlopen() it on demand?
>
> FWIW, that would not really move the needle one bit so far as
> my worries are concerned. What I'm unhappy about is the very
On Wed, Mar 19, 2025 at 5:17 PM Tom Lane wrote:
> fe-auth-oauth-curl.c:1392:49: error: data argument not used by format string
> [-Werror,-Wformat-extra-args]
> 1392 | actx_error(actx, "deleting kqueue timer: %m",
> timeout);
> | ~~
On Tue, Mar 18, 2025 at 4:08 AM Jacob Champion
wrote:
> 0001 will fix that. I think we should get that and 0002 in, ASAP. (And
> the others.)
All pushed (wasn't sure if Daniel was going to but once I got tangled
up in all that kqueue stuff he probably quite reasonably assumed that
I would :-)).
they could just use PG_IOV_MAX instead; it's perhaps a
little less clear as names go, but it's also pretty confusing that
there's a macro with the same name as a GUC...
From 1200802f3d647a8c9107b2148595dab4b6a1bd82 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Wed, 12 Feb 2025 13:
On Tue, Mar 18, 2025 at 12:59 AM Tomas Vondra wrote:
> On 3/17/25 12:36, Tomas Vondra wrote:
> > I'm still fiddling with the script, trying to increase the probability
> > of the (apparent) race condition. On one machine (old Xeon) I can hit it
> > very easily/reliably, while on a different machin
On Mon, Mar 17, 2025 at 11:52 PM Thomas Munro wrote:
> tmunro@s11-sparc:~/gettext-hacking$ gcc test.c
> tmunro@s11-sparc:~/gettext-hacking$ ./a.out
> la réponse est 42
And just to be paranoid, I checked a few more things: the .mo
definitely contains the literal "PRId64" (rear
On Mon, Mar 17, 2025 at 8:03 PM Peter Eisentraut wrote:
> On 15.03.25 03:42, Thomas Munro wrote:
> > So we should make pgoff_t a typedef for int64_t everywhere. It's a
> > bit annoying that we have to teach everyone to remember to use PRId64
> > to print it, though.
>
On Mon, Mar 17, 2025 at 8:09 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > This is not really possible. The behavior is baked deeply into
> > the gettext code. (Also note that you don't only need support in
> > xgettext, which is part of our build system, but also in the runtime
> > librar
On Sun, Mar 16, 2025 at 1:09 AM Christoph Berg wrote:
> Hmm. Is looping on EINTR worth the trouble?
I was just wondering if it might be one of those oddballs that ignores
SA_RESTART, but I guess that doesn't seem too likely (I mean, first
you'd probably have to have a reason to sleep or some othe
On Sat, Mar 15, 2025 at 4:40 AM Christoph Berg wrote:
> I'm still unconvinced if we should use statfs() instead of statvfs()
> on *BSD or if their manpage is just trolling us and statvfs is just
> fine.
>
> DESCRIPTION
>The statvfs() and fstatvfs() functions fill the structure pointed to b
On Sun, Mar 16, 2025 at 1:17 AM Laurenz Albe wrote:
> On Sat, 2025-03-15 at 13:09 +0100, Christoph Berg wrote:
> > Do we care about any of these?
> >
> > AIX
>
> We dropped support for it, but there are efforts to change that.
FWIW AIX does have it, according to its manual, in case it comes back.
On Mon, Mar 10, 2025 at 10:49 PM Peter Eisentraut wrote:
> On 02.03.25 22:08, Thomas Munro wrote:
> > Good plan, thanks. Here's a rebase.
>
> I think this went ok, and we can proceed here.
Cool, I'll post a new patch soon, but first a question about this bit:
> -
I have pushed the new pin limit patches, after some more testing and
copy editing. I dropped an unnecessary hunk (in read_stream_reset(), a
change I'd like to make but it didn't belong in this commit) and
dropped the word "Soft" from GetSoftPinLimit() as it wasn't helping
comprehension and isn't ev
On Fri, Mar 14, 2025 at 12:23 PM Andres Freund wrote:
> On 2025-03-14 11:31:47 +1300, Thomas Munro wrote:
> > 2. Somehow tell elog.c not to call CHECK_FOR_INTERRUPTS() instead.
> > Also yuck, but at least elog.c is already the right place to clean
> > state up on non-local
On Fri, Mar 14, 2025 at 5:03 AM Andres Freund wrote:
> If there is any LOG/DEBUG elog inside functions like mdreadv(), mdwritev(),
> mdextend(), be it directly or indirectly, the functions become unsafe. The
> problem is that at the end of errfinish() there is a CFI:
>
> /*
> * Ch
On Wed, Mar 12, 2025 at 8:29 AM Andres Freund wrote:
> On 2025-03-12 07:35:46 +1300, Thomas Munro wrote:
> > On Thu, Feb 27, 2025 at 11:20 PM Andres Freund wrote:
> > > On 2025-02-27 11:19:55 +1300, Thomas Munro wrote:
> > I wonder if we should use temp_buffers - 100? Th
On Thu, Feb 27, 2025 at 11:20 PM Andres Freund wrote:
> On 2025-02-27 11:19:55 +1300, Thomas Munro wrote:
> > On Wed, Feb 26, 2025 at 10:55 PM Andres Freund wrote:
> > > I was working on expanding tests for AIO and as part of that wrote a test
> > > for
> >
On Sat, Mar 8, 2025 at 6:31 AM Jacob Champion
wrote:
> On Thu, Mar 6, 2025 at 9:13 PM Thomas Munro wrote:
> > I don't see that behaviour on my Mac with a simple program, and that
> > seems like it couldn't possibly be intended.
>
> What version of macOS?
>
&
On Fri, Mar 7, 2025 at 9:57 AM Jacob Champion
wrote:
> 2) macOS's EVFILT_TIMER implementation seems to be different from the
> other BSDs. On Mac, when you re-add a timer to a kqueue, any existing
> timer-fired events for it are not cleared out and the kqueue might
> remain readable. This breaks a
(why
passing sometimes then?) but I'm sure all will become clear with your
patch...
> On Mon, Mar 3, 2025 at 8:11 PM Thomas Munro wrote:
> > I think that is telling us that a non-blocking socket can be in a
> > state that is not yet connected enough even to tell you its local
>
On Tue, Mar 4, 2025 at 1:07 PM Jacob Champion
wrote:
> # [libcurl] * getsockname() failed with errno 22: Invalid argument
Weird.
> Later, Curl reconnects via IPv6 -- this time succeeding -- but then
> the response gets mangled in some way. I assume headers are being
> truncated, based on Cur
tically using an environment variable defined under
"Repository Settings", for example:
REPO_CI_AUTOMATIC_TRIGGER_TASKS="mingw netbsd openbsd"
This will enable cfbot to turn them on by default when running tests for
the Commitfest app. It is not subject to fre
On Tue, Mar 4, 2025 at 11:39 AM Andres Freund wrote:
> On 2025-03-04 11:35:30 +1300, Thomas Munro wrote:
> > I propose to turn these on by default tomorrow, unless someone speaks
> > up with reasons why we shouldn't.
> I'm worried about enabling them by default eating
On Sun, Mar 2, 2025 at 1:37 AM Thomas Munro wrote:
> On Sat, Mar 1, 2025 at 6:24 AM Nazir Bilal Yavuz wrote:
> > I think I found the problem, sd0j's fstype is not a swap. It worked like
> > that:
> >
> > $ disklabel -E sd0
> > $ umount /usr/obj
> > $
On Tue, Mar 4, 2025 at 5:48 AM Andres Freund wrote:
> On 2025-02-24 11:26:56 +0100, Jelte Fennema-Nio wrote:
> > [1]: https://cirrus-ci.com/task/5571017969500160?logs=test_world#L256
>
> A possibly related test failure is:
>
> https://cirrus-ci.com/task/5005337046024192?logs=check_world#L259
They
On Wed, Feb 12, 2025 at 3:24 PM Thomas Munro wrote:
> On Wed, Feb 12, 2025 at 3:22 PM Andres Freund wrote:
> > On 2025-02-12 13:59:21 +1300, Thomas Munro wrote:
> > > How about just maintaining it in a new variable
> > > effective_io_combine_limit, whenever
On Tue, Dec 10, 2024 at 3:02 PM Thomas Munro wrote:
> On Thu, Dec 5, 2024 at 12:16 PM Tom Lane wrote:
> > Now you already snuck the camel's nose under the
> > tent by including stdint.h there, and maybe these additional headers
> > wouldn't do any further damag
://cirrus-ci.com/build/5275349266726912
From 68232b16632fcc9469017ec219308c798e0d5391 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 28 Feb 2025 22:19:07 +1300
Subject: [PATCH v2 1/2] ci: Use a RAM disk for NetBSD and OpenBSD.
Put the RAM disk setup for all three *BSD CI tasks into a common script,
replacing the o
On Sat, Mar 1, 2025 at 10:57 AM Jacob Champion
wrote:
> After your patch gets us past the zero timeout bug, NetBSD next runs into
>
> failed to fetch OpenID discovery document: Unsupported protocol
> (libcurl: Received HTTP/0.9 when not allowed)'
>
> ...but only for a single test (nonempty oau
On Sat, Mar 1, 2025 at 6:37 AM Jacob Champion
wrote:
> Should we maybe consider just doing that across the board, and put up
> with the inefficiency? Admittedly 1ms is a lot more dead time than
> 1ns...
Last time I checked, NetBSD is still using scheduler ticks (100hz
periodic interrupt) for all
On Tue, Feb 18, 2025 at 11:33 AM Thomas Munro wrote:
> Maybe we could try this?
>
> https://man.netbsd.org/mount_tmpfs.8
> https://man.openbsd.org/mount_tmpfs.8
NetBSD's test_world: 10:30 -> 3:23
OpenBSD test_world: 15:45 - >9:10
I think NetBSD would finish around 2n
he additional
* code complexity is worth it.
[1] https://cirrus-ci.com/task/6354435774873600
[2]
https://github.com/NetBSD/src/blob/67c7c4658e77aa4534b6aac8c041d77097c5e722/sys/kern/kern_event.c#L1375
From 7deb153caf552c9bcb380f88eddbca94be33a0c2 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date:
On Fri, Feb 28, 2025 at 2:29 PM Thomas Munro wrote:
> On Fri, Feb 28, 2025 at 11:58 AM Melanie Plageman
> wrote:
> > On Thu, Feb 27, 2025 at 1:08 PM Tom Lane wrote:
> > > I wonder if it'd be a good idea to add something like
> > >
> > >
API. Less on the order
> of a redesign and more like a separate read_stream_next_buffer()s for
> when there is per buffer data and when there isn't. And a by-value and
> by-reference version for the one where there is data.
Here's what I had in mind. Is it better?
From 68e9424b59
On Thu, Feb 27, 2025 at 11:19 AM Thomas Munro wrote:
> On Wed, Feb 26, 2025 at 10:55 PM Andres Freund wrote:
> > I was working on expanding tests for AIO and as part of that wrote a test
> > for
> > temp tables -- our coverage is fairly awful, there were many
On Wed, Feb 26, 2025 at 10:55 PM Andres Freund wrote:
> I was working on expanding tests for AIO and as part of that wrote a test for
> temp tables -- our coverage is fairly awful, there were many times during AIO
> development where I knew I had trivially reachable temp table specific bugs
> but
On Sun, Feb 23, 2025 at 4:16 AM Andres Freund wrote:
> We do count the number of lwlock share lockers and the number of buffer
> refcounts within those bits. And obviously 0 lockers/refcounts has to be
> valid. So I think the limit is correct?
Ah, right. That makes perfect sense. The 18 bits ne
On Sat, Feb 22, 2025 at 7:27 AM Andres Freund wrote:
+#define MAX_BACKENDS_BITS18
+#define MAX_BACKENDS((1 << MAX_BACKENDS_BITS)-1)
+1 for working forwards from the bits. But why not call it
PROC_NUMBER_BITS? After 024c5211 and 024c5211^, the ID for backends
is a ProcNumber,
On Sat, Feb 22, 2025 at 1:30 PM Thomas Munro wrote:
> procnumber.h seems like the right place, at least without a separate
> discussion of the ramifications of making it configurable, no? (I
> thought there were ideas about squeezing it down to 16 bits so you
> could jam two of
On Sat, Feb 22, 2025 at 5:15 AM Andres Freund wrote:
> On 2025-02-21 18:20:39 +1300, Thomas Munro wrote:
> > On Fri, Feb 21, 2025 at 9:28 AM Andres Freund wrote:
> > Do we even check the binary digits? BTW I see a place in lwlock.c
> > that still talks about 2^23-1, looks l
On Fri, Feb 21, 2025 at 6:20 PM Thomas Munro wrote:
> #define PROCNUMBER_BITS 18
> #define MAX_BACKENDS ((1 << PROCNUMBER_BITS) - 1)
> #define PROCNUMBER_CHARS DECIMAL_DIGITS_FOR_BITS(PROCNUMBER_BITS)
>
> ... with a little helper ported to preprocessor hell from Hacker
On Fri, Feb 21, 2025 at 9:28 AM Andres Freund wrote:
> The patch curently uses a hardcoded 6 for the length of MAX_BACKENDS. Does
> anybody have a good idea for how to either
>
> a) derive 6 from MAX_BACKENDS in a way that can be used in a C array size
Do we even check the binary digits? BTW I s
On Fri, Feb 21, 2025 at 11:17 AM Melanie Plageman
wrote:
> [v31-0001-Delay-extraction-of-TIDBitmap-per-page-offsets.patch]
Nice patch, seems like a straightforward win with the benefits you
explained: less work done under a lock, less work done in the second
iterator if the rest of this stuff doe
On Thu, Feb 20, 2025 at 11:53 PM Jelte Fennema-Nio wrote:
> On Thu, 20 Feb 2025 at 11:07, Thomas Munro wrote:
> > When the layout of https://commitfest.postgresql.org/52/ changed,
> > cfbot's web scraping logic could no longer find the authors :-(.
> > That's a
On Thu, Feb 20, 2025 at 10:53 PM Tatsuo Ishii wrote:
> I noticed some of entries are shown with the author field being empty.
> e.g. https://commitfest.postgresql.org/patch/5525/
When the layout of https://commitfest.postgresql.org/52/ changed,
cfbot's web scraping logic could no longer find the
On Wed, Feb 19, 2025 at 11:57 AM Jelte Fennema-Nio wrote:
> On Tue, 18 Feb 2025 at 00:38, Peter Geoghegan wrote:
> > On Mon, Feb 17, 2025 at 4:33 PM Thomas Munro wrote:
> > > This looks fantastic. Thanks so much for working on it! And all the
> > > other usability i
On Wed, Feb 19, 2025 at 3:35 PM Andres Freund wrote:
> After thinking about this for an embarassingly long time, I think there's
> actually a considerably better answer for a case like this: A function that
> returns a fixed-length string by value:
>
> - Compilers can fairly easily warn about on-s
On Fri, Feb 14, 2025 at 9:32 AM Andres Freund wrote:
> I think we'll need to add some logic in read stream that only disables advice
> after a longer sequential sequence. Writing logic for that shouldn't be too
> hard, I think? Determining the concrete cutoffs is probably harder, although I
> thin
On Fri, Feb 14, 2025 at 2:02 AM Nazir Bilal Yavuz wrote:
> On Wed, 12 Feb 2025 at 17:49, Andres Freund wrote:
> > Obviously not your fault, but I do think it's pretty crazy that with the
> > same
> > available resources, netbsd and openbsd take considerably longer than linux
> > and freebsd, whi
On Mon, Feb 17, 2025 at 10:03 PM Jelte Fennema-Nio wrote:
> The cfbot statuses will get filled in over the next few (12?) hours.
> The first few are already available[2]. If you notice any problems,
> please let me know.
This looks fantastic. Thanks so much for working on it! And all the
other
On Mon, Feb 17, 2025 at 6:55 PM Kirill Reshke wrote:
> Just out of curiosity, should we `Assert(*index + n <
> stream->queue_size);` in `read_stream_index_advance_n`?
No: it is allowed to be >= queue_size temporarily, but if so we
subtract queue_size. The result should be equal to (index + n) %
On Mon, Feb 17, 2025 at 5:55 PM Thomas Munro wrote:
> The solution we agreed on is to introduce a way for StartReadBuffers()
> to communicate with future calls, and "forward" pinned buffers between
> calls. The function arguments don't change, but its "buffers"
stream.c separately, as the complexity is
obviously increasing a bit (especially with out-of-order streams,
about which more soon).
[1]
https://www.postgresql.org/message-id/CA%2BhUKGLxH1tsUgzZfng4BU6GqnS6bKF2ThvxH1_w5c7-sLRKQw%40mail.gmail.com
From 57cc7f12e4a7799c581d4ced054dfbb2663c5b81 Mon S
On Mon, Feb 17, 2025 at 7:02 AM Andres Freund wrote:
> I don't really know enough about IPC::Run's internals to answer. My
> interpretation of how it might work, purely from observation, is that it opens
> one tcp connection for each "pipe" and that that's what's introducing the
> potential of reo
On Sat, Feb 15, 2025 at 12:50 PM Melanie Plageman
wrote:
> It fixed the issue (after an off-list correction to the patch by Thomas).
Thanks! It's green again.
On Sat, Feb 15, 2025 at 12:03 PM Tom Lane wrote:
> Thomas Munro writes:
> > Here's a patch. Is there a tidier way to write this?
>
> Hmm, I think not with the current set of primitives. We could think
> about refactoring them, but that's not a job for a band-ai
On Sat, Feb 15, 2025 at 10:50 AM Thomas Munro wrote:
> On Sat, Feb 15, 2025 at 7:30 AM Melanie Plageman
> wrote:
> > Seems valgrind doesn't like this [1]. I'm looking into it.
>
> Melanie was able to reproduce this on her local valgrind and
> eventually we figured
On Sat, Feb 15, 2025 at 7:30 AM Melanie Plageman
wrote:
> Seems valgrind doesn't like this [1]. I'm looking into it.
Melanie was able to reproduce this on her local valgrind and
eventually we figured out that it's my fault. I put code into
read_stream.c that calls wipe_mem(), thinking that that
On Fri, Feb 14, 2025 at 12:11 PM Melanie Plageman
wrote:
> I've done some clean-up including incorporating a few off-list pieces
> of minor feedback from Andres.
I've been poking, reading, and trying out these patches. They look good to me.
Tiny nit, maybe this comment could say something less
On Fri, Feb 14, 2025 at 11:50 AM Thomas Munro wrote:
> Yeah I guess you could in theory also stream pointers to individual
> uncompressed result objects allocated with palloc(), that is point a
> point in the per-buffer-data and make the consumer free it, but that
> has other pr
On Fri, Feb 14, 2025 at 5:52 AM Melanie Plageman
wrote:
> On Thu, Feb 13, 2025 at 11:28 AM Tomas Vondra wrote:
> > On 2/13/25 17:01, Melanie Plageman wrote:
> > I know it's not changing how much memory we allocate (compared to
> > master). I haven't thought about the GinScanEntry - yes, flexible
regression with eic=1 (look for "column" of red cells). That's a bit
> > unfortunate, because eic=1 is the default value.
>
> So, I feel pretty confident after even more analysis today with Thomas
> Munro that all of the parallel cases with effective_io_concurrency ==
>
On Wed, Feb 12, 2025 at 3:22 PM Andres Freund wrote:
> On 2025-02-12 13:59:21 +1300, Thomas Munro wrote:
> > How about just maintaining it in a new variable
> > effective_io_combine_limit, whenever either of them is assigned?
>
> Yea, that's probably the least bad way.
1 - 100 of 1664 matches
Mail list logo
