On Fri, 13 Jun 2025 at 15:57, Peter Eisentraut wrote:
> That doesn't address the concern that it's confusing what kind of object
> \close operates on. There are named and unnamed cursors (= portals),
> after all.
Agreed. My vote is for \closeprepared as that aligns with the libpq function.
On Tue, 17 Jun 2025 at 06:21, Ashutosh Bapat
wrote:
> I like this as well. I feel "In Progress" doesn't convey that the
> column contains the dates when the CFs are active. It can be easily
> confused with "In progress" CF. How about just "Dates" or "Duration"?
I decided to overhaul the table a b
On Tue, 17 Jun 2025 at 06:41, Tom Lane wrote:
> Yeah. I think it might be smarter to push these changes a bit earlier
> than the 30th, maybe by a week? Better to file down any rough edges
> before we start the new CF.
Sounds good to me. Unless there are big objections, I'll deploy this
on the 2
On Sat, 31 May 2025 at 13:47, Jelte Fennema-Nio wrote:
>
> I realized two smallish commitfest app improvements were merged but
> not deployed yet for quite some time.
> 1. There's now a similar summary at the top of the "Personal
> Dashboard" page, as is on regul
On Mon, 9 Jun 2025 at 17:54, Florents Tselai wrote:
> Here’s a quick attempt that makes %S substitue for a search_path
> Like
> \set PROMPT1 'user:%n search_path: %S'
+ else
+ return PQuser(pset.db);
That seems like a copy paste error. If we don't have data for it, we
should either use
On Sat, 7 Jun 2025 at 20:52, Lauri Siltanen wrote:
> I need to switch search_paths often. It would be tremendously helpful to see
> the current search_path in the prompt.
That feature should be pretty easy to implement, now that search_path
is marked as GUC_REPORT in PG18. Basically you need to
On Sat, 7 Jun 2025 at 00:12, Andres Freund wrote:
> I assume this is due to the fairly high iteration count we use by default?
Maybe... But looking closer at the PgBouncer code another option that
seems pretty likely is that PgBouncer is regenerating a secret over
and over again, if users store t
First of all, I'm definitely in favor of sunsetting md5 password auth myself.
However, I would like to share a possible issue that users might run
into while we're doing this: Apparently the overhead of scram-256 is
much higher in some PgBouncer setups. I expect this to be mostly
setups where ther
I realized two smallish commitfest app improvements were merged but
not deployed yet for quite some time.
1. There's now a similar summary at the top of the "Personal
Dashboard" page, as is on regular commitfest pages. Thanks to Akshat
Jaimini.
2. Selecting the committer for a committed patch from
On Fri, 30 May 2025 at 16:38, Tom Lane wrote:
> I don't have an opinion about the merits of this exact change, but
> I wish somebody would go through all our DEBUGn messages and come up
> with some coherent proposal for what the various levels should be
> used for. Right now I think those choices
On Fri May 30, 2025 at 1:55 PM CEST, David Rowley wrote:
By my count, those who think we should change log_buffers to true are:
Robert [1], Michael Christofides [2], Fujii [3].
+1 for me on changing the default. It just seems confusing to have
different defaults for auto_explain and EXPLAIN. I'
can be ignored while still
showing other (more predictable) DEBUG messages.
From 535e7afd0f5cc6939ff9981f47159e4f88f03b9f Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Fri, 30 May 2025 14:22:49 +0200
Subject: [PATCH v1] Reduce DEBUG level of catcache refreshing messages
When testing extens
On Thu, 29 May 2025 at 13:12, Dave Cramer wrote:
> Agreed that nobody upgrades a client from 2.0 but is there value in keeping
> the history ?
Yeah, maybe.
> Perhaps another section which would be "Changes in 3.x" ?
If we decide to keep it I think it would be best to have all protocol
changes
On Thu, 29 May 2025 at 00:29, Dave Cramer wrote:
> I found another place where the docs should be updated. The Changes since
> Protocol 2.0
I think it makes sense to have a dedicated page like this that lists
any protocol changes that we do. But I think the current structure
doesn't make much se
On Fri, 16 May 2025 at 12:05, Daniel Gustafsson wrote:
>
> > On 16 May 2025, at 11:52, Jelte Fennema-Nio wrote:
>
> > Does anyone have strong opposition to this? To be clear, it means we don't
> > run CI on patches created by piping "git diff" to
On Fri, 16 May 2025 at 12:24, Jacob Champion
wrote:
>
> On Fri, May 16, 2025 at 12:12 PM Tom Lane wrote:
> > That outcome seems entirely horrible to me. If you want to flag the lack
> > of a commit message somehow, fine, but don't prevent CI from running.
>
> Personally I also prefer nudges to g
In the "Scaling PostgreSQL Development" unconference session. One of the
problems that came up was that people don't follow "best practices". The
response to that was that people don't know what the best practices are
(nor that they are important to follow), because we don't enforce them.
Based on
On Tue, 6 May 2025 at 21:29, Nathan Bossart wrote:
>
> Every once in a while, I find myself wanting to use regdatabase for
> something like current_database()::regdatabase, and I'm always surprised
> when I inevitably rediscover that it doesn't exist.
+1 for the idea. I keep running into this too
On Mon, 5 May 2025 at 21:07, Jonathan S. Katz wrote:
> Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
It might make sense to add a small sentence like "this release
introduces version 3.2 of the wire protocol, but libpq still uses 3.0
by default. This is the first new proto
On Sun, 4 May 2025 at 22:28, Alexander Borisov wrote:
> I'm actually a bit confused, and didn't expect such a heated discussion
> about creating an entry about my patch in Release Notes.
I definitely understand this. And to make my own opinion on this
matter extremely clear: I *do* think it's imp
On Fri, 2 May 2025 at 04:45, Bruce Momjian wrote:
> I have committd the first draft of the PG 18 release notes.
Some suggestions for additional commits to list for the items in the changelog:
1. I think 5070349102af12832c8528651c8ed18b16346323 should be listed
as a commit for "Add libpq connectio
On Sun, 4 May 2025 at 03:21, Bruce Momjian wrote:
> So the logic is something I posted to this thread already:
>
> So, a few things. First, these set of commits was in a group of 10
> that
> I added since there have been complaints in the past that optimizer
> improvement
On Sat, 3 May 2025 at 18:19, Bruce Momjian wrote:
> I moved the item and added some text, patch attached.
LGTM, apart from the typo in the word "client' (it's spelled as
"cliient" in the diff).
Noticed a few other small things when rereading:
1. "Add libpq functions and environment..." should b
On Sat, 3 May 2025 at 02:06, Bruce Momjian wrote:
>
> On Sat, May 3, 2025 at 01:46:29AM +0200, Jelte Fennema-Nio wrote:
> > On Fri, 2 May 2025 at 04:45, Bruce Momjian wrote:
> > >
> > > I have committd the first draft of the PG 18 release notes. The
On Fri, 2 May 2025 at 04:45, Bruce Momjian wrote:
>
> I have committd the first draft of the PG 18 release notes. The item
> count looks strong:
Thanks for all the work. Some notes:
1. There's currently no mention that protocol version 3.2 was
introduced in this release. I'm not sure where/how
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
1 - 100 of 643 matches
Mail list logo
