On Fri, 25 Apr 2025 at 12:22, George MacKerron wrote:
> I know the documentation has now been changed to reflect that ‘system’
> actually means OpenSSL.
I didn't realize that. I'm definitely not in favor of that doc change.
It's describing behaviour that I believe is incorrect, as if it's
actual
On Thu, 24 Apr 2025 at 23:52, Jelte Fennema-Nio wrote:
> How about we add a *compile time*
> option that allows the person that compiles libpq to choose which cert
> store it should use if sslrootcert=system is provided. Something like
> --system-cert-store=openssl and --syste
On Thu, 24 Apr 2025 at 18:46, Jacob Champion
wrote:
>
> On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> > I'm generally in favor of making sslmode=verify-full the effective
> > default somehow.
>
> +many
Yes, +many
> Not to derail things too much, but I'd also like a postgress://
> sc
On Wed, 23 Apr 2025 at 17:47, George MacKerron wrote:
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> thi
On Thu, 24 Apr 2025 at 10:54, Peter Eisentraut wrote:
> The cut-off in practice for these things is usually RHEL. PG18
> currently still supports RHEL 7, which appears to come with Python 3.6.
> Seeing that the small problem with the test script was easily fixed, I
> think we should stick with th
On Wed, 23 Apr 2025 at 13:24, Devrim Gündüz wrote:
> psycopg is included in RHEL 8, but PGDG packages are up2date (2.7.5 vs
> 2.9.5) so they override OS packages. That is why things will break.
>
> A solution would be creating our own psycopg2 (likely for Python 3.12)
> package, update all PGDG pa
On Wed, 23 Apr 2025 at 10:59, Devrim Gündüz wrote:
> The most notable one would be Psycopg (2 and 3). Plus Patroni
> dependencies. There may be a couple of more.
I meant more in what ways do these things break? Since you're actually
the one that's packaging them, I'd expect that you could make th
On Wed, 23 Apr 2025 at 11:13, Devrim Gündüz wrote:
> You are right, our side is fixable. However many packages in the
> upstream also depend on Psycopg. I don't want to create a Linux
> distribution based on RHEL 8 built against Python 3.9 (or 3.1x) :-)
I'm confused. The upstream RHEL8 repo depen
On Wed, 23 Apr 2025 at 00:33, Jacob Champion
wrote:
> As long as the need to backport to PG18 doesn't freeze that
> conversation in place, I suppose.
I'm confused. Are you intending to backport new test infra to PG18?
Looking at the amount of python code that we currently have, I agree
with Tom:
On Wed, 23 Apr 2025 at 10:15, Devrim Gündüz wrote:
> I would love to have such an evidence -- but I don't have :) In the last
> couple of weeks I've also been thinking of bumping every single Python
> piece in the PGDG RPM repository to 3.9 (at least) on RHEL 8, but that
> will break many things i
On Tue, 22 Apr 2025 at 21:26, Jacob Champion
wrote:
> - str.removeprefix/suffix() (3.9)
The way you replaced this does not have the same behaviour in the case
where the prefix/suffix is not part of the string. removeprefix/suffix
will not remove any characters in that case, but your code will alw
tl;dr I think requiring support of Python 3.9 for PG18 would probably
be reasonable and save us a bunch of maintenance burden over the next
5 years.
On Tue, 22 Apr 2025 at 21:41, Tom Lane wrote:
> Yeah, that. The distros that are still shipping older Pythons
> are LTS distros where part of the d
On Thu, 17 Apr 2025 at 03:57, Tristan Partin wrote:
> I spent some time exploring the Meson build a bit, and I realized that
> C++ support in PGXS is tied to LLVM enablement. Checking the autotools
> build in the configure.ac script indicates that that is not the case for
> it.
Thank you for look
made in v18.
Seems fine to me.
On Wed, 16 Apr 2025 at 02:03, Jacob Champion
wrote:
>
> On Tue, Apr 15, 2025 at 3:25 PM Jelte Fennema-Nio wrote:
> > I don't understand why it should be a server option instead of a user
> > mapping option. Having it be a server option means
On Tue, 15 Apr 2025 at 22:48, Noah Misch wrote:
> yet be a
> postgres_fdw server option, postgres_fdw code can make it so. postgres_fdw
> already has explicit code to reclassify the "user" option.
I don't understand why it should be a server option instead of a user
mapping option. Having it be
On Tue, 15 Apr 2025 at 23:34, Noah Misch wrote:
> That said, maybe having
> PQpipelineSync() was a mistake, since I think it's just PQsendPipelineSync() +
> PQflush().
Yes, IMO that's pretty much the case. But we cannot remove that
function because of backwards compatibility.
Note that for all t
On Tue, 15 Apr 2025 at 19:53, Jacob Champion
wrote:
> But let me turn this around, because we currently have the opposite
> problem: if someone comes in and adds a completely new feature
> depending on libcurl, and you want OAuth but you do not want that new
> feature -- or vice-versa -- what do y
On Fri, 11 Apr 2025 at 22:26, Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Jacob
> Champion, who has accepted an invitation to become our newest PostgreSQL
> committer.
>
> Please join us in wishing Jacob much success and few reverts!
Congrats! Well deser
f popen[1] that suddenly seemed
more trouble than it's worth.
[1]:
https://github.com/freebsd/freebsd-src/blob/c98367641991019bac0e8cd55b70682171820534/lib/libc/gen/popen.c#L63-L181
From 5dbab2ccf0d74313dbc2cbaeb418346de8cc2f48 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Sun, 23 Fe
On Fri, 11 Apr 2025 at 21:39, Fujii Masao wrote:
> While checking the code in older branches, I noticed that the returned
> protocol version is always the latest version supported by the server.
> However, as we discussed, in master, the server may return the version
> requested by the client. The
On Fri, 11 Apr 2025 at 22:57, Dave Cramer wrote:
> Well this isn't quite true since if you request 3.0 and have invalid options
> it will return 3.0, which is not the highest supported minor version.
Probably good to update this section too then to be similarly correct
as your already updated se
On Thu, Apr 10, 2025, 07:08 Jacob Champion
wrote:
> Christoph noted that this was also confusing from the packaging side,
> earlier, and Daniel proposed -Doauth-client/--with-oauth-client as the
> feature switch name instead.
>
+1
Next up: staticlibs.
>
I think your suggestion of not using any
On Wed, Apr 9, 2025, 10:58 Jacob Champion
wrote:
> Is it acceptable/desirable for a build, which has not been configured
> --with-libcurl, to still pick up a compatible OAuth implementation
> installed by the distro? If so, we can go with a "bare" dlopen(). If
> that's not okay, I think we will p
On Mon, 17 Mar 2025 at 16:48, Jacob Champion
wrote:
>
> On Sun, Mar 16, 2025 at 6:49 AM Daniel Gustafsson wrote:
> > IIRC the reasoning has been that if a rogue user can inject an environment
> > variable into your session and read your files it's probably game over
> > anyways.
>
> (Personally
On Fri, 21 Mar 2025 at 18:53, Tom Lane wrote:
>
> Peter Eisentraut writes:
> > - If I'm the committer for a patch but not a reviewer, and the patch is
> > in "needs review" status, then the patch is formally speaking not
> > actionable by me and should not be under "Patches that are ready for
> >
On Tue, 25 Feb 2025 at 17:11, Nathan Bossart wrote:
>
> On Tue, Feb 25, 2025 at 04:42:37PM +0100, Magnus Hagander wrote:
> > Thanks goes to both you and the previous responders - I did manage to mute
> > this thread away and missed the early replies, but got Jeltes the other day
> > which brought
On Wed, 19 Mar 2025 at 14:15, torikoshia wrote:
> BTW based on your discussion, I thought this patch could not be merged
> anytime soon. Does that align with your understanding?
Yeah, that aligns with my understanding. I don't think it's realistic
to get this merged before the code freeze, but I
On Tue, 18 Mar 2025 at 13:43, Daniel Gustafsson wrote:
> Since there is disagreement over this, we should either 1) go ahead with the
> latest patch without an env var and revisit the discussion during v19; 2)
> adding the env var back into the patch as PGSSLKEYLOGFILE or; 3) postponing
> all
> o
On Tue, 18 Mar 2025 at 09:55, Anthonin Bonnefoy
wrote:
> I've added additional tests when piping queries with ';':
> - I've reused the same scenario with \sendpipeline: single query,
> multiple queries, flushes, syncs, using COPY...
> - Using ';' will replace the unnamed prepared statement. It's a
o solves that.
From 579ac166ab91f5b5e7c2d79d2c9a7f5e4a52fc6e Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Tue, 18 Mar 2025 01:31:57 +0100
Subject: [PATCH v12] Allow logging backtraces in more cases
We previously only had the backtrace_functions GUC to control when
backtraces were logged. B
On Mon, 10 Feb 2025 at 14:23, torikoshia wrote:
> Thanks for reviewing the patch and comments!
> Fixed issues you pointed out and attached v2 patch.
This patch needs a rebase, because it's failing to compile currently.
So I marked this as "Waiting on Author" in the commitfest app.
On Mon Feb 24, 2025 at 12:01 PM CET, Jelte Fennema-Nio wrote:
Right after pressing send I realized I could remove two more useless
lines...
Rebased patchset attached (trivial conflict against pg_noreturn
changes).
From 249ebbac1b6c01b99795cfe9b0201ab7ee6bacfa Mon Sep 17 00:00:00 2001
From
On Tue, 4 Mar 2025 at 02:21, Jelte Fennema-Nio wrote:
>
> The next commitfest app release is planned for March 18th
I deployed the latest release of the commitfest app. Below is a
changelog that's slightly updated.
1. Major change: There's a new /me page which shows a dashboard
On Thu, 6 Mar 2025 at 16:36, vignesh C wrote:
> But it applies neatly for me and Jim also at [3]. Any idea why patch
> apply fails with CFbot whereas it passes in our environment?
Okay, the cause of this seems to be that the CFbot currently uses "git
apply --3way", not "git am --3way". For some r
On Sun, 9 Mar 2025 at 03:21, vignesh C wrote:
> Couple of suggestions: a) No need to show CI status as "Needs rebase,"
> "Not processed," etc., for committed patches.
Do you mean specifically for committed ones? Or just for any patch
with a "closed" status.
> b) Can we add a filter
> for "Needs
On Fri, 7 Mar 2025 at 17:42, Tom Lane wrote:
> Hm, don't you *want* a failure if the patch is already applied?
It's pretty common that in a larger patchset the first 1-2
small/trivial patches get committed before the rest. Having to then
send an additional email, resubmitting the rest of the patc
On Fri, 7 Mar 2025 at 15:37, Michael Banck wrote:
> On Fri, Mar 07, 2025 at 09:17:46AM -0500, Robert Haas wrote:
> > Why wouldn't the cloud provider just change add 'trusted = true' to
> > the relevant control files instead of doing this?
>
> That would be possible, but maybe the cloud provider i
On Fri, 7 Mar 2025 at 14:58, Robert Haas wrote:
> I see that Jelte walked this comment back, but I think this issue
> needs more discussion. I'm not intrinsically against having a role
> like pg_execute_server_programs that allows escalation to superuser,
> but I don't see how it would help a clou
On Fri, 7 Mar 2025 at 11:26, Andreas Karlsson wrote:
> Out of curiosity: do you track which method works? I would expect
> everything to be applied with either git am or patch which can be
> applied with git apply making git apply technically unnecessary.
I think we need all of them...
- git appl
On Tue, 25 Feb 2025 at 02:11, Michael Paquier wrote:
> Initial digestion has gone well.
One thing I've noticed is that \startpipeline throws warnings when
copy pasting multiple lines. It seems to still execute everything as
expected though. As an example you can copy paste this tiny script:
\sta
On Thu, 6 Mar 2025 at 18:39, Jelte Fennema-Nio wrote:
>
> On Thu, 6 Mar 2025 at 18:10, Tom Lane wrote:
> > Please see if you can make it use patch(1). IME git is too
> > stiff-necked about slightly stale patches no matter which
> > subcommand you use.
>
> It was
On Thu, 6 Mar 2025 at 18:10, Tom Lane wrote:
> Please see if you can make it use patch(1). IME git is too
> stiff-necked about slightly stale patches no matter which
> subcommand you use.
It was using patch(1) in the past for that reason, but with --3way I
was able to get "git apply" to apply pa
On Thu, 6 Mar 2025 at 18:08, Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 04.03.25 21:37, Jelte Fennema-Nio wrote:
> >> 1. This new homepage includes open patches from*all* commitfests. And
> >> there's currently no page with that information.
>
&g
On Tue, 4 Mar 2025 at 22:01, Andreas Karlsson wrote:
> What I need to see is the below (plus any future commit fests).
Thanks you for describing how you use the current homepage. That's
super helpful.
> I am interested in the dates when commit fests open and close
These are the same exact 5 mon
On Tue, 4 Mar 2025 at 20:46, Daniel Gustafsson wrote:
> My preference would be not have any relative times or dates at all and just
> show the date as is.
I pushed a change that both improves the rendering of relative
datetimes and also allows people to choose to disable that and just
show the da
On Tue, 4 Mar 2025 at 22:04, Peter Geoghegan wrote:
>
> On Tue, Mar 4, 2025 at 4:02 PM Jelte Fennema-Nio wrote:
> > You have to create a *new* account to do so, because the staging auth
> > and prod auth
> > systems are separate. Then you can mark yourself as author/revie
On Tue, 4 Mar 2025 at 21:57, Peter Geoghegan wrote:
>
> On Tue, Mar 4, 2025 at 3:50 PM Robert Haas wrote:
> > On Mon, Mar 3, 2025 at 8:21 PM Jelte Fennema-Nio wrote:
> > > As always, please test out the current staging website[1] to give some
> > > feedback.
>
On Tue, 4 Mar 2025 at 17:15, Peter Eisentraut wrote:
> I think the option of having a list of things that I'm involved in as an
> author *or* reviewer is actually very useful and something I have wanted
> from time to time. But that is apparently not accessible using the
> normal search/filter me
On Tue, 4 Mar 2025 at 11:35, Álvaro Herrera wrote:
> https://commitfest.postgresql.org/me
I've restored the original homepage and moved this new dashboard
(minus the "Archive" link) to /me:
https://commitfest-test.postgresql.org/me/
On Tue, 4 Mar 2025 at 18:25, Peter Geoghegan wrote:
> From the looks of the screen shot that you posted (can't seem to find
> the same dashboard view on https://commitfest-test.postgresql.org?),
The dashboard is only available if you login. You probably have to
create an account to do so, because
On Tue, 4 Mar 2025 at 17:31, Peter Geoghegan wrote:
> > Peter Geoghegan suggested adding a "dashboard" of this
> > kind. Feedback on this is very welcome, but depending on the
> > complexity I don't know when I'll get to it. I'll be a bit more busy
> > the next few weeks and also have some holiday
On Tue, 4 Mar 2025 at 16:29, Peter Eisentraut wrote:
> Another small complaint: I don't like this style of relative times. (I
> have also complained about it for the buildfarm status in the past.) I
> suppose both styles are useful like 50% of the time, but I'll tell you
> some of my reasoning:
On Tue, 4 Mar 2025 at 13:36, Amit Kapila wrote:
>
> On Tue, Mar 4, 2025 at 4:05 PM Álvaro Herrera wrote:
> > I think showing different pages on the same URL depending on whether
> > you're logged in or not is not great UX.
> >
>
> +1. The default should be what we see today, and there should be s
On Tue, 4 Mar 2025 at 10:22, Peter Eisentraut wrote:
> I don't know if I like that. I can see the point of getting to the
> action quicker, but this sort of obscures the hierarchy of the site and
> the data. Before it was like, select a commitfest, select a filter,
> here are some patches. Now
On Mon, 17 Feb 2025 at 10:17, Jelte Fennema-Nio wrote:
>
> The next release of the commitfest app will take place March 4th.
>
> The user facing changes are:
> 1. The form for creating a commitfest entry now contains all the
> commitfest entry fields, instead of redirecting t
On Sat, 1 Mar 2025 at 17:33, Tom Lane wrote:
> But IMO you still haven't made an acceptable case
> for deciding that these data structures aren't private to numeric.c.
> What behaviors do you actually need that aren't accessible via the
> existing exported functons?
FWIW in pg_duckdb we would def
On Mon, 24 Feb 2025 at 18:24, Robert Haas wrote:
>
> On Sat, Feb 22, 2025 at 9:58 AM Jelte Fennema-Nio wrote:
> > My patchset in the other protocol thread needed a rebase. So I took
> > that as an opportunity to rebase this patchset on top of it, because
> > this seems t
On Mon Feb 24, 2025 at 11:58 AM CET, Jelte Fennema-Nio wrote:
Ughh, a compiler warning snuck on windows during some of my final
refactoring. Fixed now.
Right after pressing send I realized I could remove two more useless
lines...
From ec72e05e87c73dee3de73f9a6586e8e8db2d919e Mon Sep 17 00:00
On Mon Feb 24, 2025 at 10:56 AM CET, Jelte Fennema-Nio wrote:
Great! Attached are the updated other patches, I think I addressed all
feedback.
Ughh, a compiler warning snuck on windows during some of my final
refactoring. Fixed now.
From ec72e05e87c73dee3de73f9a6586e8e8db2d919e Mon Sep 17 00
The test introduced in bb86141 turns out to be flaky in CI[1] with the
following error message:
[03:40:43.047] stderr:
[03:40:43.047] # Failed test 'connect : matches'
[03:40:43.047] # at
/tmp/cirrus-ci-build/src/test/postmaster/t/003_start_stop.pl line 78.
[03:40:43.047] # 'psql: error: connectio
l
feedback.
From ec72e05e87c73dee3de73f9a6586e8e8db2d919e Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Sun, 23 Feb 2025 16:52:29 +0100
Subject: [PATCH v4 1/3] Adds a helper for places that shell out to system()
We need to call system() in a few places, and to do so safely we need
some pre
On Sun Feb 23, 2025 at 3:51 PM CET, Jelte Fennema-Nio wrote:
Attached is an updated patch that fixes the tests and changes the
whitespace as discussed (including removing a spurious second space
before the ON, which I noticed while changing it). As well as a seprate
patch that changes the &q
fixes the tests and changes the
whitespace as discussed (including removing a spurious second space
before the ON, which I noticed while changing it). As well as a seprate
patch that changes the "c" alias to "d".
From 9762388cfe3b16b22a468ebe29b613e2b81088f3 Mon Sep 17 00:00:0
On Sun, 23 Feb 2025 at 07:49, Kirill Reshke wrote:
> So, are we +1 or -1 on moving this forward?
+1 from me. Marked as ready for committer.
This was very painful to read. +1 on making changes. Both for a
culture change to require less urgency over the weekend if it's a
minor failure, and probably also a tooling change to make this less of
a problem in general.
On Sat, 22 Feb 2025 at 04:38, Robert Haas wrote:
>
> On Fri, Feb 21, 2025
penSSL's CRYPTO_memcmp.
One open question on the last patch is: Document what the maximum size
of the cancel key is that the client can expect? I think Jacob might
have some ideas on that.
From 0168dd6d463eb989d2e944c8acccf7cc620f5db1 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date
On Tue, 18 Feb 2025 at 09:51, Jelte Fennema-Nio wrote:
> Rebased it, and moved some of the new header definitions around to
> hopefully not have to rebase again.
This required another rebase, but I've decided that I think it'll be
most fruitful to continue the discussion on pro
On Thu, 20 Feb 2025 at 11:07, Thomas Munro wrote:
>
> 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/
On Wed, 19 Feb 2025 at 17:24, Daniel Gustafsson wrote:
> There is functionality in the CF app to send an email to authors with a patch
> still in the previous commitfest, it would be quite trivial to alert everyone.
>
> We should of course also add some form of messaging in the app itself to make
On Wed, 19 Feb 2025 at 17:32, Robert Haas wrote:
> What *I* think is incredibly painful is that I can spend an
> hour going through the CommitFest and not find a single patch that
> needs a review. And it's not just me.I have heard of multiple cases
> of people wanting to get involved in patch rev
On Wed, 19 Feb 2025 at 16:02, Daniel Gustafsson wrote:
> The opposite, which was discussed at length at FOSDEM, was to ask authors to
> click a single button once a month at most. If that level of engagement is
> too
> much to ask then maybe said authors should question why they in return ask
>
Since the next commitfest is starting soon, I think for now we should
move all entries still open in the January commitfest to the March
commitfest. There's a bunch that are still not moved, that I know
should be moved. For example[1] which we discussed at FOSDEM and seems
to have a reasonable chan
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 improvements too.
>
> +1.
Thanks all, I'm also very happy that it's deployed.
> I very much
On Tue, 18 Feb 2025 at 23:57, Jelte Fennema-Nio wrote:
> > I like "Useful links that you can use and bookmark", but I'd prefer if
> > there was only one link that I needed to bookmark. That is, I'd like
> > it if "Your entries in the current commitfest
On Tue, 18 Feb 2025 at 22:15, Bruce Momjian wrote:
> Looking at the live version, I can sort the "Stats" column from smallest
> to largest, but not from largest to smallest. Is this intended?
The next release to prod in ~2 weeks will have that as one of the new
features (courtesy of Akshat).
Yo
-blocking PQCancel work.
I have inlined the parts of emails that are relevant to this patch
below. That way others don't have to dissect that thread. (for context
this patch is often, but not always, called patch 0002 in the original
thread).
My initial email containing the patch[4]:
On Mon, 2
On Thu, 27 Jun 2024 at 12:43, Jelte Fennema-Nio wrote:
> Attached is a rebased patchset of my previous proposal, including a
> few changes that Michael preferred:
Rebased again. (got notified because of the new commitfest rebase emails)
The first patch should be trivial to commit at le
s(void)
> >max_safe_fds, usable_fds, already_open);
> > }
> >
> > +
> > /*
> > * Open a file with BasicOpenFilePerm() and pass default file mode for the
> > * fileMode parameter.
>
> Unrelated change.
Ugh, yeah I guess I added th
The next release of the commitfest app will take place March 4th.
The user facing changes are:
1. The form for creating a commitfest entry now contains all the
commitfest entry fields, instead of redirecting to the entries edit
page after creating it.
2. When creating a commitfest entry, the autho
On Fri, 31 Jan 2025 at 15:23, Jelte Fennema-Nio wrote:
> The next commitfest app release will take place on February 17 and
> will contain the following user facing changes:
In my part of the world it's February 17th now. So this is now deployed.
A big recommendation, check the &qu
ed.
From 8e964db585989734a5f6c1449ffb4c62e1190a6a Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Tue, 11 Feb 2025 22:04:44 +0100
Subject: [PATCH v2 1/3] Bump pgbench soft open file limit (RLIMIT_NOFILE) to
hard limit
The default open file limit of 1024 is extremely low, given modern
resou
On Wed, 12 Feb 2025 at 12:32, Fujii Masao wrote:
> > What do you think if we simply don't log anything for SKIP LOCKED?
>
> Implementing both NOWAIT and SKIP LOCKED could take time and make the patch
> more complex. I'm fine with focusing on the NOWAIT case first as an initial
> patch.
I think t
.com
[7]: https://github.com/abiosoft/colima/discussions/836
[8]:
https://www.postgresql.org/message-id/flat/29663.1007738957%40sss.pgh.pa.us#2079ec9e2d8b251593812a3711bfe9e9
From ecf7fc5f34b4e025eaa4dda809874f18dfdb24b4 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Tue, 11 Feb 2025 19:15:36 +0100
On Tue, 11 Feb 2025 at 17:19, Andres Freund wrote:
> Yes, at least initially:
Ah, then I understand your point of view much better. Still I think we
could easily frame it as: If you enable io_uring, you also get these
additional fancy stats.
Also afaict the items don't have to mean that
> 1) it
On Tue, 11 Feb 2025 at 16:36, Andres Freund wrote:
> Shrug. It means that it'll not work in what I hope will be the default
> mechanism before long. I just can't get excited for that. In all likelihood
> it'll result in bug reports that I'll then be on the hook to fix.
My assumption was that io_
On Tue, 11 Feb 2025 at 00:53, Andres Freund wrote:
> > I mostly meant worker based AIO, yes. I haven't checked how accurately these
> > are kept for io_uring. I would hope they are...
>
> It does look like it is tracked.
nice!
> > The thing is that you'd often get completely misleading stats. So
On Mon, 10 Feb 2025 at 14:31, Andres Freund wrote:
> I think it'll always be a subset of use. It doesn't make sense to use DIO for
> a small databases or untuned databases. Or a system that's deliberately
> overcommmitted.
Thanks, that's useful context.
> But this will also not work with AIO w/
On Sun, 9 Feb 2025 at 19:05, Tom Lane wrote:
>
> Andres Freund writes:
> > I'm somewhat against this patch, as it's fairly fundamentally incompatible
> > with AIO. There's no real way to get information in this manner if the IO
> > isn't executed synchronously in process context...
Hmm, I had no
On Fri, 13 Dec 2024 at 16:59, Michael Christofides
wrote:
>
> > I've pushed the main patch.
>
> Woohoo! And thank you. I've already seen quite a lot of positivity around the
> commit on Twitter[1][2][3].
I wanted to highlight this other patch[1] by Atsushi Torikoshi, which
adds "actual filesyste
On Sat, 8 Feb 2025 at 14:54, Jelte Fennema-Nio wrote:
> I'll play around with it a bit next week.
Okay, I played around with it and couldn't find any issues. I marked
the patch as "ready for committer" in the commitfest app[1], given
that all feedback in my previous em
On Mon, 27 Jan 2025 at 10:05, torikoshia wrote:
> Therefore, I believe it would be reasonable to report the raw values
> as-is, as they should still be useful for understanding storage I/O
> activity.
Sounds reasonable.
Below some feedback on the patch. It's all really minor. The patch
looks gre
On Thu, 6 Feb 2025 at 01:29, Tom Lane wrote:
>
> Peter Geoghegan writes:
> > Evidently this new policy is why my skip scan patch series wasn't
> > being tested by CI.
>
> Well no, the reason CI wasn't testing anything was the cfbot was
> broken. See nearby "CFBot is broken" thread.
That's not e
On Wed, 5 Feb 2025 at 21:05, Daniel Gustafsson wrote:
> For reference, you meant 53 right?
Yes, I meant 53
> If the
> CFBot always need one in "Future" state we should document that to make sure
> we
> don't miss that going forward (and perhaps automate it to make sure we dont
> make manual wor
On Wed, 5 Feb 2025 at 20:29, Jelte Fennema-Nio wrote:
> I'll look into fixing that soonish. I took a quick look and it seems
> related to some unexpected response from the Cirrus API.
Okay I think I got it running again. It didn't like that there was no
commitfest with num
On Wed, 5 Feb 2025 at 20:21, Tom Lane wrote:
>
> Andres Freund writes:
> > On 2025-02-05 14:09:02 -0500, Tom Lane wrote:
> >> Hard to tell, considering the cfbot has been completely wedged
> >> since Sunday.
>
> > It passed on the postgres repo just before this commit:
> > https://cirrus-ci.com
On Wed, 5 Feb 2025 at 00:22, Andres Freund wrote:
> Pushed like that.
>
> I'll watch CI and BF over the next hours.
I guess you probably noticed, but in case you didn't: CI on windows is
still broken.
On Tue, 4 Feb 2025 at 17:27, Álvaro Herrera wrote:
> I think this has potential for excessive clutter. I propose that, if
> we're going to have a column with addition/deletions, we have two
> things:
>
> 1. the total number of addition and deletions in the whole patch
>series, for the last pa
On Mon, 3 Feb 2025 at 13:56, Aleksander Alekseev
wrote:
> > """
> > The status of this patch cannot be changed in this commitfest. You
> > must modify it in the one where it's open!
> > """
>
> Ooops, never mind.
I also thought that error was pretty silly. So it will be changed in
the next releas
On Sun, 2 Feb 2025 at 22:26, Tom Lane wrote:
> Hmm, our convention is definitely that the numbers start with 1,
> so I do not want to make this change. Maybe we should change
> the code instead.
That would require any extensions that use the _0.out suffix to update
all those files to use _1.out
On Fri, 31 Jan 2025 at 15:23, Jelte Fennema-Nio wrote:
> You can try out these changes on the staging environment
It seems that someone tried it out, and found a 500 error when
searching by Message-ID. That's fixed now.
I also fixed some broken links to CirrusCI on the patch page.
1 - 100 of 618 matches
Mail list logo
