On Fri, 7 Apr 2023 at 01:28, Amit Kapila wrote:
>
> On Wed, Apr 5, 2023 at 5:58 AM Peter Smith wrote:
>
> > PSA patches to add those tab completions.
>
> LGTM, so pushed.
I moved this to the next CF but actually I just noticed the thread
starts with the original patch being pushed. Maybe we shou
On Thu, 19 Jan 2023 at 18:19, Andres Freund wrote:
>
> On 2023-01-19 22:19:10 +0100, Tomas Vondra wrote:
>
> > So I'm a bit unsure about this patch. I doesn't seem like it can perform
> > better than read-ahead (although perhaps it does, on a different storage
> > system).
>
> I really don't see t
On Sat, 8 Apr 2023 at 11:37, Greg Stark wrote:
>
> c) Pick out the Bug Fixes, cleanup patches, and other non-feature
> patches that might be open issues for v16.
So on further examination it seems there are multiple category of
patches that are worth holding onto rather than shifting to the next
On Fri, 16 Sept 2022 at 03:33, Zhang Mingli wrote:
>
> On Sep 16, 2022, 14:47 +0800, Richard Guo , wrote:
>
> How about add it to the CF to not lose track of it?
>
> Will add it, thanks~
I guess not losing track of it is only helpful if we do eventually
commit it. Otherwise we would rather lose t
Fwiw the cfbot seems to have some failing tests with this patch:
[19:05:11.398] # Failed test 'initial test data replicated'
[19:05:11.398] # at t/030_sequences.pl line 75.
[19:05:11.398] # got: '1|0|f'
[19:05:11.398] # expected: '132|0|t'
[19:05:11.398]
[19:05:11.398] # Failed test 'advance sequ
Hm. The cfbot has a fairly trivial issue with this with a unused variable:
18:36:17.405] In file included from ../../src/include/access/nbtree.h:1184,
[18:36:17.405] from verify_nbtree.c:27:
[18:36:17.405] verify_nbtree.c: In function ‘palloc_btree_page’:
[18:36:17.405] ../../src/include/access/nb
Only a few more days remain before feature freeze. We've now crossed
over 100 patches committed according to the CF app:
Status summary: March 15March 22March 28April 4
Needs review: 152 128 116 96
Waiting on Author: 42 36
On Sun, 26 Feb 2023 at 19:11, Melanie Plageman
wrote:
>
> This is cool! Thanks for working on this.
> I had a chance to review your patchset and I had some thoughts and
> questions.
It looks like this patch got a pretty solid review from Melanie
Plageman in February just before the CF started. It
This looks like it was a good discussion -- last summer. But it
doesn't seem to be a patch under active development now.
It sounds like there were some design constraints that still need some
new ideas to solve and a new patch will be needed to address them.
Should this be marked Returned With Fe
On Thu, 16 Mar 2023 at 05:25, Drouvot, Bertrand
wrote:
>
> My plan was to get [1] done before resuming working on the "Split index and
> table statistics into different types of stats" one.
> [1]: https://commitfest.postgresql.org/42/4106/
Generate pg_stat_get_xact*() functions with Macros ([1]
It looks like in November 2022 Tomas Vondra said:
> I did a quick initial review of the v20 patch series.
> I plan to do a
more thorough review over the next couple days, if time permits.
> In
general I think the patch is in pretty good shape.
Following which Antonin Houska updated the patch resp
Given that there's been no updates since September 22 I'm going to
make this patch Returned with Feedback. The patch can be resurrected
when there's more work done -- don't forget to move it to the new CF
when you do that.
--
Gregory Stark
As Commitfest Manager
On Fri, 24 Mar 2023 at 14:48, Egor Rogov wrote:
>
> Done.
> There is one thing I'm not sure what to do about. This check:
>
> if (typentry->typtype != TYPTYPE_RANGE)
> ereport(ERROR,
> (errcode(ERRCODE_DATATYPE_MISMATCH),
>errmsg("expected arr
On Mon, 13 Mar 2023 at 17:17, Nathan Bossart wrote:
>
> On Fri, Mar 10, 2023 at 12:28:28PM -0500, Tom Lane wrote:
> > A quick grep for pg_usleep with large intervals finds rather more
> > than you touched:
> >
> > [...]
> >
> > Did you have reasons for excluding the rest of these?
>
> I'm still lo
On Mon, 6 Mar 2023 at 00:30, Michał Kłeczek wrote:
>
> Hi All,
>
> I just wanted to ask about the status and plans for this patch.
> I can see it being stuck at “Waiting for Author” status in several commit
> tests.
Sadly it seems to now be badly in need of a rebase. There are large
hunks failin
On Mon, 13 Feb 2023 at 05:41, Peter Eisentraut
wrote:
>
> I think this patch requires an up-to-date summary and explanation. The
> thread is over a year old and the patch has evolved quite a bit. There
> are some test changes that are not explained. Please provide more
> detail so that the patc
On Sun, 29 Jan 2023 at 21:24, David Rowley wrote:
>
> I've moved this patch to the next CF. This patch has a dependency on
> what's being proposed in [1].
The referenced patch was committed March 19th but there's been no
comment here. Is this patch likely to go ahead this release or should
I mov
Ah, another thread with a bouncing email address...
Please respond to to thread from this point to avoid bounces.
--
Gregory Stark
As Commitfest Manager
It looks like this remaining work isn't going to happen this CF and
therefore this release. There hasn't been an update since January when
Dean Rasheed posted a review.
Unless there's any updates soon I'll move this on to the next
commitfest or mark it returned with feedback.
--
Gregory Stark
As
On Tue, 3 Jan 2023 at 14:16, Tom Lane wrote:
>
> Vik Fearing writes:
>
> > I don't think we should add that syntax until I do get it through the
> > committee, just in case they change something.
>
> Agreed. So this is something we won't be able to put into v16;
> it'll have to wait till there's
FYI I attached this thread to
https://commitfest.postgresql.org/42/3777 which I believe is the same
issue. I mistakenly had this listed as a CF entry with no discussion
for a long time due to that missing link.
--
Gregory Stark
As Commitfest Manager
On Wed, 31 Aug 2022 at 20:52, Alexander Korotkov wrote:
>
> I'll continue work on this patch. The rebased patch is attached. It
> implements stop events as configure option (not runtime GUC option).
It looks like this patch isn't going to be ready this commitfest. And
it hasn't received much di
Status summary:
Needs review: 116.
Waiting on Author: 30.
Ready for Committer: 32.
Committed: 94.
Moved to next CF: 17.
Returned with Feedback: 6.
Rejected: 6.
Withdrawn: 18.
Total: 319.
Ok, here are the patches that have been stuck in "Waiting
on Author" for a while. I divided t
On Wed, 26 Oct 2022 at 02:08, Bharath Rupireddy
wrote:
>
> I'm attaching the v9 patch set herewith after rebasing. Please review
> it further.
It looks like neither reviewer has been really convinced this is the
direction they want to go and I think that's why the thread has been
pretty dead sinc
This patch has been "Needs Review" and bouncing from CF to CF. It
actually looks like it got quite a bit of design discussion and while
James Coleman seems convinced of its safety it doesn't sound like Tom
Lane and Robert Haas are yet and it doesn't look like that's going to
happen in this CF.
I t
On Tue, 5 Jul 2022 at 11:29, Tom Lane wrote:
>
> No, that's not acceptable. CREATE OR REPLACE should always produce
> exactly the same final state of the object, but in this case we cannot
> change the underlying function if the operator already exists.
It sounds like this patch isn't the direct
On Tue, 14 Mar 2023 at 14:54, Gregory Stark (as CFM)
wrote:
>
> CFBot is failing with this test failure... I'm not sure if this just
> represents a timing dependency or a bad test or what?
CFBot is now consistently showing these test failures. I think there
might actually be
> Ok, sounds reasonable. Maybe just add a comment to that effect.
> This needs regression test support for the feature and some minimal
> documentation that shows how to make use of it.
Hm. It sounds like this patch is uncontroversial but is missing
documentation and tests? Has this been address
On Sun, 19 Feb 2023 at 04:58, Nitin Jadhav
wrote:
>
> > This doesn't pass the tests, because the regression tests weren't adjusted:
> > https://api.cirrus-ci.com/v1/artifact/task/5937624817336320/testrun/build/testrun/regress/regress/regression.diffs
>
> Thanks for sharing this. I have fixed this
I think it's clear we aren't going to be taking this patch in its
current form. Perhaps there are better ways to do what these files do
(I sure think there are!) but I don't think microoptimizing the
copying is something people are super excited about. It sounds like
rethinking how to make these fu
On Thu, 29 Sept 2022 at 15:34, Tom Lane wrote:
>
> Martin Kalcher writes:
> > New patch: array_shuffle() and array_sample() use pg_global_prng_state now.
>
> I took a closer look at the patch today. I find this behavior a bit
> surprising:
>
It looks like this patch received useful feedback and
On Fri, 25 Nov 2022 at 07:22, Peter Eisentraut
wrote:
>
> Just for completeness, over in the other thread the feedback was that
> this functionality is better put into pg_resetwal.
So is that other thread tracked in a different commitfest entry and
this one completely redundant? I'll mark it Reje
On Sun, 22 Jan 2023 at 18:22, Tomas Vondra
wrote:
>
> I wonder if we have other functions doing something similar, i.e.
> accepting a polymorphic type and then imposing additional restrictions
> on it.
Meh, there's things like array comparison functions that require both
arguments to be the same
On Mon, 17 Oct 2022 at 14:59, Robert Haas wrote:
>
> On Sat, Oct 15, 2022 at 1:47 AM Amit Langote wrote:
>
> But I think the bigger problem for this patch set is that the
> design-level feedback from
> https://www.postgresql.org/message-id/CA%2BTgmoaiTNj4DgQy42OT9JmTTP1NWcMV%2Bke0i%3D%2Ba7%3DVgnz
On Thu, 26 Jan 2023 at 15:55, Brar Piening wrote:
>
> On 18.01.2023 at 06:50, Brar Piening wrote:
>
> > I'll give it a proper look this weekend.
>
> It turns out I didn't get a round tuit.
>
> ... and I'm afraid I probably will not be able to work on this until
> mid/end February so we'll have to
On Sun, 29 Jan 2023 at 05:20, Mikhail Gribkov wrote:
>
> The problem is obviously in the newly added second line of the following
> clause:
> COMPLETE_WITH("ALTER COLUMN", "OWNER TO", "RENAME",
> "SET SCHEMA", "SET (", "RESET (");
>
> "set
On Mon, 20 Mar 2023 at 14:34, Gregory Stark (as CFM)
wrote:
>
> Pruning bouncing email address -- please respond from this point in
> thread, not previous messages.
Oh for heaven's sake. Trying again to prune bouncing email address.
Please respond from *here* on the th
Pruning bouncing email address -- please respond from this point in
thread, not previous messages.
--
Gregory Stark
As Commitfest Manager
Is this feedback enough to focus the work on the right things?
I feel like Marina Polyakova pointed out some real confusing behaviour
and perhaps there's a way to solve them by focusing on one at a time
without making large changes in the code.
Perhaps an idea would be to have each module provide
On Wed, 12 Oct 2022 at 01:10, Michael Paquier wrote:
>
> On Tue, Sep 13, 2022 at 05:31:05PM +0900, Kyotaro Horiguchi wrote:
> > And ExportSnapshot repalces oversized subxip with overflowed.
> >
> > So even when GetSnapshotData() returns a snapshot with oversized
> > subxip, it is saved as just "ov
On Mon, 16 Jan 2023 at 09:47, vignesh C wrote:
>
> Jeite, please post an updated version with the fixes. As CommitFest
> 2023-01 is currently underway, this would be an excellent time to
> update the patch.
Hm. This patch is still waiting on updates. But it's a bug fix and it
would be good to get
On Mon, 23 Jan 2023 at 11:54, Mark Wong wrote:
fficient way to communicate useful information.
>
> Yeah, I will try to cover all the data types we ship. :) I'll keep at
> it and drop the code examples.
I assume this isn't going to happen for this commitfest? If you think
it is then shout otherwi
On Mon, 12 Dec 2022 at 11:37, Frédéric Yhuel wrote:
>
> I've planned to work on it full time on week 10 (6-10 March), if you
> agree to bear with me. The idea would be to bootstrap my brain on it,
> and then continue to work on it from time to time.
Any updates on this patch? Should we move it to
On Wed, 4 Jan 2023 at 10:05, Ibrar Ahmed wrote:
>
> Thanks, I have modified everything as suggested, except one point
>
> > Don't use variable format strings. They're hard to read and they
> > probably defeat compile-time checks that the arguments match the
> > format string. You could use a "*" f
So, sorry I've been a bit under the weather but can concentrate on the
commitfest now. I tried to recapitulate the history but the activity
log only goes back a certain distance on the web. If I can log in to
the database I guess I could construct the history from sql queries if
it was important.
It looks like the patch is failing a test by not dumping
login_event_trigger_func? I'm guessing there's a race condition in the
test but I don't know. I also don't see the tmp_test_jI6t output file
being preserved in the artifacts anywhere :(
https://cirrus-ci.com/task/6391161871400960?logs=test_w
CFBot is failing with this test failure... I'm not sure if this just
represents a timing dependency or a bad test or what?
[09:44:49.937] --- stdout ---
[09:44:49.937] # executing test in
/tmp/cirrus-ci-build/build-32/testrun/authentication/001_password
group authentication test 001_password
[09:
FYI this looks like it needs a rebase due to a conflict in copy.c and
an offset in pgoutput.c.
Is there anything specific that still needs review or do you think
you've handled all Peter's concerns? In particular, is there "a
comprehensive description of what it is trying to do"? :)
So what is the status of this patch?
It looks like you received some feedback from Emre, Tom, Ronan, and
Alvaro but it also looks like you responded to most or all of that.
Are you still blocked waiting for feedback? Anything specific you need
help with?
Or is the patch ready for commit now? In w
So I was seeing that this patch needs a rebase according to cfbot.
However it looks like the review feedback you're looking for is more
of design questions. What jumbling is best to include in the feature
set and which is best to add in later patches. It sounds like you've
gotten conflicting feedb
The pgindent run in b6dfee28f is causing this patch to need a rebase
for the cfbot to apply it.
It does look like a rebase for meson.build would be helpful. I'm not
marking it waiting on author just for meson.build conflicts but it
would be perhaps more likely to be picked up by a committer if it's
showing green in cfbot.
It looks like this needs a big rebase in fea-uth.c fe-auth-scram.c and
fe-connect.c. Every hunk is failing which perhaps means the code
you're patching has been moved or refactored?
It looks like Daniel Gustafsson, Andres, and Tom have all weighed in
on this patch with at least a neutral comment (+-0 from Andres :)
It looks like the main concern was breaking physical replicas and that
there was consensus that as long as single-user mode worked that it
was ok?
So maybe it's t
So This patch has been through a lot of commitfests. And it really
doesn't seem that hard to resolve -- Pavel has seemingly been willing
to go along whichever way the wind has been blowing but honestly it
kind of seems like he's just gotten drive-by suggestions and he's put
a lot of work into t
The CFBot says this patch is failing but I find it hard to believe
this is related to this patch...
2023-03-05 20:56:58.705 UTC [33902][client backend]
[pg_regress/btree_index][18/750:0] STATEMENT: ALTER INDEX
btree_part_idx ALTER COLUMN id SET (n_distinct=100);
2023-03-05 20:56:58.709 UTC [33902
I'm sorry, It seems this is failing again? It's Makefile and
meson.build again :(
Though there are also
patching file contrib/pg_stat_statements/sql/oldextversions.sql
can't find file to patch at input line 1833
and
|--- a/contrib/pg_stat_statements/sql/pg_stat_statements.sql
|+++ b/contrib/pg
It looks like this needs a rebase and at a quick glance it looks like
more than a trivial conflict. I'll mark it Waiting on Author. Please
update it back when it's rebased
--
Gregory Stark
As Commitfest Manager
This patch too is conflicting on meson.build. Are these two patches
interdependent?
This one looks a bit more controversial. I'm not sure if Tom has been
convinced and I haven't seen anyone else speak up.
Perhaps this needs a bit more discussion of other options to solve
this issue. Maybe it can
It looks like this patch needs a quick rebase, there's a conflict in
the meson.build.
I'll leave the state since presumably this would be easy to resolve
but it would be more likely to get attention if it's actually building
cleanly.
http://cfbot.cputube.org/patch_42_4023.log
On Tue, 28 Feb 2023
Sorry, I wasn't feeling very well since Friday. I'm still not 100% but
I'm going to try to do some triage this afternoon.
There are a few patches that need a rebase. And a few patches failing
Meson builds or autoconf stages -- I wonder if there's something
unrelated broken there?
But what I think
On Thu, 5 Jan 2023 at 02:59, Antonin Houska wrote:
>
> vignesh C wrote:
>
> > The patch does not apply on top of HEAD as in [1], please post a rebased
> > patch:
And again...
Setting this to Waiting on Author for the moment.
Do you think this patch is likely to be ready for this release or th
On Thu, 19 Jan 2023 at 16:12, Dmitry Koval wrote:
>
> >The patch does not apply on top of HEAD ...
>
> Thanks!
> Here is a fixed version.
Sorry to say, but this needs a rebase again... Setting to Waiting on Author...
Are there specific feedback needed to make progress? Once it's rebased
if you
On Mon, 20 Feb 2023 at 23:04, Thomas Munro wrote:
>
> Done like that in this version. This is the version I'm thinking of
> committing, unless someone wants to argue for another level.
FWIW the cfbot doesn't understand this patch series. I'm not sure why
but it's only trying to apply the first (
On Wed, 8 Feb 2023 at 15:04, Andres Freund wrote:
>
> Attached is a current, quite rough, prototype. It addresses some of the points
> raised, but far from all. There's also several XXXs/FIXMEs in it. I changed
> the file-ending to .txt to avoid hijacking the CF entry.
It looks like this patch h
On Sun, 15 Jan 2023 at 11:44, Joseph Koshakow wrote:
>
> On Sat, Jan 14, 2023 at 4:22 PM Joseph Koshakow wrote:
> I've gone ahead and updated the patch to only look at the months field.
> I'll submit this email and patch to the Feb commitfest.
It looks like this patch needs a (perhaps trivial)
On Mon, 6 Feb 2023 at 23:48, Kyotaro Horiguchi wrote:
>
> Thank you for the comment!
>
> At Fri, 3 Feb 2023 08:42:52 +0100, Heikki Linnakangas wrote
> in
> > I want to call out this part of this patch:
Looks like this patch has received some solid feedback from Heikki and
you have a path forwar
Looks like you have a path forward on this and it's not ready to
commit yet? In which case I'll mark it Waiting on Author?
On Fri, 13 Jan 2023 at 13:38, Andres Freund wrote:
>
> On 2023-01-13 10:36:49 +0100, Drouvot, Bertrand wrote:
>
> > I'll first look at 1).
>
> Makes sense.
>
> > And it looks
On Wed, 1 Mar 2023 at 14:48, Jelte Fennema wrote:
> > > This looks like it needs a rebase.
>
> done
Great. Please update the CF entry to Needs Review or Ready for
Committer as appropriate :)
--
Gregory Stark
As Commitfest Manager
On Thu, 12 Jan 2023 at 03:46, Anthonin Bonnefoy
wrote:
>
>
> That would make sense. I've created a new patch with everything moved in
> pgstat_report_checkpointer().
> I did split the checkpointer flush in a pgstat_flush_checkpointer() function
> as it seemed more readable. Thought?
This patch
On Thu, 9 Feb 2023 at 05:43, Aleksander Alekseev
wrote:
>
> >> I don't buy your argument about DO UPDATE needing to be brought into
> >> line with DO NOTHING. In any case I'm pretty sure that Tom's remarks
> >> in 2016 about a behavioral inconsistencies (which you cited) actually
> >> called for m
On Wed, 11 Jan 2023 at 04:00, Jelte Fennema wrote:
>
> I'm working on a new patchset for my commitfest entry.
So I'll set it to "Waiting on Author" pending that new patchset...
--
Gregory Stark
As Commitfest Manager
On Wed, 1 Mar 2023 at 04:04, Andrei Zubkov wrote:
>
> Hi!
>
> I've attached a new version of a patch - rebase to the current master.
The CFBot (http://cfbot.cputube.org/) doesn't seem to like this. It
looks like all the Meson builds are failing, perhaps there's something
particular about the test
73 matches
Mail list logo
