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 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 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 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 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_
.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 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 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 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 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.
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 Thu, 23 Jan 2025 at 13:57, Jelte Fennema-Nio wrote:
> # Proposal for new process
I just announced an upcoming commitfest app release[1], following the
discussion on this topic at the FOSDEM dev meeting.
The rest of the conclusion is that we'll roughly follow the approach
outlined
On Wed, 11 Dec 2024 at 10:38, David Rowley wrote:
> I've pushed the main patch. I'm not planning on pushing the
> auto_explain.log_buffers default change unless there's a bit more
> discussion about it.
FreeBSD CFBot seems broken on a pg_stat_statements test because of
this change:
https://api.c
On Tue, 10 Dec 2024 at 11:44, Anthonin Bonnefoy
wrote:
> num_queries (2nd element in the pipeline status prompt) is now used to
> track queued queries that were not flushed (with a flush request or
> sync) to the server. It used to count both unflushed queries and
> flushed queries.
I skimmed the
t some comments where they could be
added. This gets the explicit cast support for free btw, because the
transform step removes that for the text type.
From 133ee1f88ec2ca732bfc6084e99a7f7d4a2710c5 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Mon, 16 Dec 2024 14:33:46 +0100
Subject: [PA
On Mon, 16 Dec 2024 at 21:55, Tom Lane wrote:
> Oh, well if you're willing to cheat like that, sure ;-). I was
> speaking of replacing the existing logic with something that looked
> only at the post-analysis tree.
Yeah, alright. That's not really something that I think we can do
without introdu
On Mon, 16 Dec 2024 at 22:00, Melanie Plageman
wrote:
> Users wishing to debug slow connection establishment have little
> visibility into which steps take the most time. We don't expose any
> stats and none of the logging includes durations.
Two thoughts:
1. Would it make sense to also expose th
On Sun, 15 Dec 2024 at 10:00, Alexander Lakhin wrote:
> shows that the subscription and publication tests are not concurrent-safe,
> because modifying the same pg_database entry might fail with the "tuple
> concurrently updated" error.
This seems related to this thread about concurrency issues in
Attached is a
simple POC of option 1.
From 8eac6bb24b4f8f55e0edb05cf856f1e8eb048308 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio
Date: Mon, 16 Dec 2024 14:33:46 +0100
Subject: [PATCH v1] Use last string-literal subscript as default column name
---
src/backend/parser/parse_target.c | 30 +
On Mon, 16 Dec 2024 at 16:34, Tom Lane wrote:
> I dunno, this seems to be putting an undue amount of emphasis on
> one very specific usage pattern. Why should it matter whether
> the subscripts are string literals or not? What will happen when
> ruleutils decides to dump those expressions with th
On Mon, 16 Dec 2024 at 19:32, Tom Lane wrote:
> No, sorry, I was just illustrating the behavior with HEAD.
> The important part of this is not the assigned alias
> but the visible cast.
Then I don't think I understand what you're trying to say. While I
think it would be good to not have an explic
On Fri, 20 Dec 2024 at 01:54, Andres Freund wrote:
> Arguably the configuration *did* tell us, by having a higher hard limit...
>
> But opting into a higher rlimit, while obviously adhering to the hard limit
> and perhaps some other config knob, seems fine?
Yes, totally fine. That's exactly the
On Thu, 21 Nov 2024 at 02:31, Tom Lane wrote:
> Anyway, given that info, Jelte's unapplied 0002 patch earlier in the
> thread is not the answer, because this is about dropping a query
> cancel not about losing a timeout interrupt.
Agreed that 0002 does not fix the issue re-reported by Andres (let
On Thu, 5 Dec 2024 at 16:35, Eric Hanson wrote:
> When pgbouncer is in transaction mode, the pipeline doesn't stop when
> the transaction ends? Mayhaps I have the common misunderstanding.
When PgBouncer is in transaction mode, the server connection will only
be unlinked, when PgBouncer receives
(Resent because sending to both -hackers and -www gets emails put in
the moderation queue, and I don't want to introduce that delay to all
replies. If you received the previous version because you're in the CC
please only reply to this one)
# Background
As some of you might have noticed I've been
On Thu, 23 Jan 2025 at 01:25, Jacob Brazeal wrote:
>>
>> Magnus wants reviews before deployment to be required, in an effort to
>> get as close-to-perfect commits as possible. I, on the other hand,
>> think that the benefit of close-to-perfect commits is not worth the
>> delays in deploying that
On Sun, 26 Jan 2025 at 19:09, Yura Sokolov wrote:
> Given history of libxz backdoor, I'd fear to give "commit access" for
> anything critical to rather fresh member of community.
That's definitely a valid concern in the general case, but I wouldn't
call myself a fresh member of the community. I'v
On Mon, 27 Jan 2025 at 05:38, Umar Hayat wrote:
> +1 in github you can enforce a minimum number of reviewers. IMO there
> should be a minimum of two reviewers and one of the reviewers should
> be from the security group/role.
In a perfect world I'd agree, but I don't think there are currently
eno
On Sat, 25 Jan 2025 at 06:29, Akshat Jaimini
wrote:
> I'll be happy to submit a PR with some basic tests on the repository.
Sounds good, what basic tests do you have in mind?
I have this auto-formatting PR open that also adds some github
actions: https://github.com/JelteF/commitfest/pull/1
Since about ~11 hours ago the ecpg test is consistently failing on
Window with this error[1]:
> Could not open file
> C:/cirrus/build/src/interfaces/ecpg/test/compat_informix/dec_test.c for
> reading
I took a quick look at possible causes but couldn't find a clear
winner. My current guess is th
On Sat, 11 Jan 2025 at 10:40, Peter Eisentraut wrote:
>
> I want to register that I'm not a fan of this change:
Thanks for the feedback. Much bigger changes are coming soon (spoiler:
cfbot integration). Feedback is definitely welcome on those changes
too.
> Rationale: It puts the least important
On Thu, 31 Oct 2024 at 18:15, Jelte Fennema-Nio wrote:
>
> On Thu, 31 Oct 2024 at 15:50, Heikki Linnakangas wrote:
> > Bikeshedding time:
>
> Another few options:
Okay let's just pick one of the available options. The current
situation where we use different termino
On Mon, 7 Oct 2024 at 22:21, Jelte Fennema-Nio wrote:
> Is this blocked on anything? I feel it's ready to merge at this point.
> I'd really like to not have this problem with trailing whitespace in
> sgml files anymore.
I noticed Peter added some additional rules to .gitattrib
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
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 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 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 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 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 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
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 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
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 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 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 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 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 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
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 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
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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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.
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 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 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 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
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
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
-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
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
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
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
>
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 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, 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 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 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 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 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 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 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 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 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 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 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 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
501 - 600 of 712 matches
Mail list logo
