David Rowley writes:
> Unsure if such a feature is worthwhile. I think maybe not for just
> min(ctid)/max(ctid). However, there could be other reasons, such as
> the transform OR to UNION stuff that Tom worked on a few years ago.
> That needed to eliminate duplicate rows that matched both OR branc
On 4/8/24 21:47, Robert Haas wrote:
> On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas wrote:
>> Can you elaborate, which patches you think were not ready? Let's make
>> sure to capture any concrete concerns in the Open Items list.
>
> ...
>
> - Incremental backup could have all sorts of terri
Andrew Dunstan writes:
> I quite like the triage idea. But I think there's also a case for being
> more a bit more flexible with those patches we don't throw out. A case
> close to my heart: I'd have been very sad if the NESTED piece of
> JSON_TABLE hadn't made the cut, which it did with a few
On Tue, Apr 09, 2024 at 01:16:02AM +0200, Tomas Vondra wrote:
> I don't feel too particularly worried about this. Yes, backups are super
> important because it's often the only thing you have left when things go
> wrong, and the incremental aspect is all new. The code I've seen while
> doing the Co
On Tue, 9 Apr 2024 at 11:02, Tom Lane wrote:
>
> David Rowley writes:
> > Unsure if such a feature is worthwhile. I think maybe not for just
> > min(ctid)/max(ctid). However, there could be other reasons, such as
> > the transform OR to UNION stuff that Tom worked on a few years ago.
> > That nee
On Mon, Apr 8, 2024 at 9:49 PM Andres Freund wrote:
>
> On 2024-04-08 16:01:41 +0530, Amit Kapila wrote:
> > Pushed.
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=adder&dt=2024-04-08%2012%3A04%3A27
>
> This unfortunately is a commit after
>
Right, and thanks for the report. Hou-San
On Mon, Apr 08, 2024 at 05:42:35PM -0400, Andrew Dunstan wrote:
> Arguably the fact that it points nowhere is a good thing. But feel free to
> replace it with something else. It doesn't have to be URLs at all. That
> happened simply because it was easy to extract from a very large piece of
> JSON I
Similar to f736e188c, I've attached a patch that fixes up a few
misusages of the StringInfo functions. These just swap one function
call for another function that is more suited to the use case.
I've also attached the patch that I used to find these. That's not
intended for commit.
I feel like i
On Tue, Apr 09, 2024 at 12:53:21PM +1200, David Rowley wrote:
> Similar to f736e188c, I've attached a patch that fixes up a few
> misusages of the StringInfo functions. These just swap one function
> call for another function that is more suited to the use case.
>
> I've also attached the patch th
On Mon, Apr 8, 2024 at 9:24 PM Robert Haas wrote:
>
> Hi,
>
> I'm concerned that the failover slots feature may not be in
> sufficiently good shape for us to ship it. Since this test file was
> introduced at the end of January, it's been touched by a total of 16
> commits, most of which seem to be
Robert Haas writes:
> On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas wrote:
>> Can you elaborate, which patches you think were not ready? Let's make
>> sure to capture any concrete concerns in the Open Items list.
> Hi,
> I'm moving this topic to a new thread for better visibility and less
Attached is a patch which adjusts the copyright years of 2023 that
have crept in this year from patches that were written last year and
committed without adjusting this to 2024.
The patch isn't produced by src/tools/copyright.pl as that'll
transform files which are new and only contain "2023" to b
David Rowley writes:
> Similar to f736e188c, I've attached a patch that fixes up a few
> misusages of the StringInfo functions. These just swap one function
> call for another function that is more suited to the use case.
> I feel like it's a good idea to fix these soon while they're new
> rather
David Rowley writes:
> Attached is a patch which adjusts the copyright years of 2023 that
> have crept in this year from patches that were written last year and
> committed without adjusting this to 2024.
> The patch isn't produced by src/tools/copyright.pl as that'll
> transform files which are
Hi,
Here is an experimental patch for read_stream.c. The basic idea is
that when read_stream_next_buffer() gives you a page P1, it should
also tell the CPU to prefetch the header of the next page P2, and so
on. However, I recognise that its lack of timing control may be a
fundamental flaw (see
On Sat, Mar 30, 2024 at 04:50:26PM -0400, Robert Haas wrote:
> An awful lot of what we do operates on the principle that we know the
> people who are involved and trust them, and I'm glad we do trust them,
> but the world is full of people who trusted somebody too much and
> regretted it afterwards
On Mon, Apr 08, 2024 at 10:36:41PM -0400, Tom Lane wrote:
> We *should* do this sometime before branching v17, but I'm not
> in any hurry. My thought here is that some of these late changes
> might end up getting reverted, in which case touching those files
> would add a bit more complexity to the
On Mon, Apr 08, 2024 at 12:29:43PM +0300, Andrey M. Borodin wrote:
> On 8 Apr 2024, at 11:55, Michael Paquier wrote:
>> Uh, I did not understand this. Because commit message was about
>> stabiilzizing tests, not extending coverage.
Okay, it is about stabilizing an existing test.
> Also, should w
On Mon, 8 Apr 2024 at 23:56, Robins Tharakan wrote:
> #3 0x0083ed84 in WaitLatch (latch=,
> wakeEvents=wakeEvents@entry=41, timeout=60,
> wait_event_info=wait_event_info@entry=150994946) at latch.c:538
> #4 0x00907404 in pg_sleep (fcinfo=) at misc.c:406
> #17 0x008
On Mon, Apr 08, 2024 at 11:11:07AM +0300, Andrey M. Borodin wrote:
> This is kind reminder that this thread is waiting for your response.
> CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Hmm, is that productive? This patch has been waiting on author since
the 1st of February, an
út 9. 4. 2024 v 0:55 odesílatel Tom Lane napsal:
> Erik Wienhold writes:
> > On 2024-04-07 06:33 +0200, Tom Lane wrote:
> >> I suspect it'd be much more robust if we could remove the comment from
> >> the expr->query string. No idea how hard that is.
>
> > I slept on it and I think this can be
On Tue, 11 Apr 2023 at 17:43, David Rowley wrote:
>
> On Fri, 11 Jun 2021 at 13:44, David Rowley wrote:
> > Anyway, I'll set an alarm for this time next year so I can check on
> > how many inconsistencies have crept back in over the development
> > cycle.
>
> That alarm went off today.
>
> There
Hi
This idea is due to Robert Haas, who complained that he feared that
the streaming I/O API already worked like this. It doesn't, but it
could! Here is a concept patch to try it out.
Normally, read_stream_next_buffer() spits out buffers in the order
that the user's callback generated block num
Typo. fix:
-attempted first. If the server ejectes GSS encryption, SSL is
+attempted first. If the server rejects GSS encryption, SSL is
Erik--- doc/src/sgml/libpq.sgml.orig 2024-04-09 06:28:36.254541932 +0200
+++ doc/src/sgml/libpq.sgml 2024-04-09 06:30:55.818541454 +0200
@@ -18
Here's a rebase. I decided against committing this for v17 in the
end. There's not much wrong with it AFAIK, except perhaps an
unprincipled chopping up of writes with large io_combine_limit due to
simplistic flow control, and I liked the idea of having a decent user
of smgrwritev() in the tree, a
On Mon, Apr 08, 2024 at 12:23:56PM +0300, Nazir Bilal Yavuz wrote:
> On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
>> As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
>> is fixed already.
>> Perhaps it's worth rechecking...
>>
>> [1]
>> https://www.postgresql.org/me
On 09/04/2024 07:40, Erik Rijkers wrote:
Typo. fix:
-attempted first. If the server ejectes GSS encryption, SSL is
+attempted first. If the server rejects GSS encryption, SSL is
Fixed, thanks!
--
Heikki Linnakangas
Neon (https://neon.tech)
On Mon, Apr 8, 2024 at 7:01 PM Zhijie Hou (Fujitsu)
wrote:
>
> Thanks for pushing.
>
> I checked the BF status, and noticed one BF failure, which I think is related
> to
> a miss in the test code.
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=adder&dt=2024-04-08%2012%3A04%3A27
>
> Fro
On Tue, Apr 9, 2024 at 5:01 PM Michael Paquier wrote:
> On Mon, Apr 08, 2024 at 12:23:56PM +0300, Nazir Bilal Yavuz wrote:
> > On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
> >> As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
> >> is fixed already.
> >> Perhaps it'
On Tue, Apr 09, 2024 at 09:48:18AM +0900, Michael Paquier wrote:
> There is no direct check on test_json_parser_perf.c, either, only a
> custom rule in the Makefile without specifying something for meson.
> So it looks like you could do short execution check in a TAP test, at
> least.
While readin
On 9/4/2024 09:12, Tom Lane wrote:
I have another one that I'm not terribly happy about:
Author: Alexander Korotkov
Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
Transform OR clauses to ANY expression
Because I'm primary author of the idea, let me answer.
I don't k
hi all,
We have an interesting problem, where PG went to PANIC due to stuck
spinlock case.
On careful analysis and hours of trying to reproduce this(something that
showed up in production after almost 2 weeks of stress run), I did some
statistical analysis on the RNG generator that PG uses to crea
On Mon, Apr 08, 2024 at 05:42:05PM +, Leung, Anthony wrote:
> Are you suggesting that we check if the backend is B_AUTOVAC in
> pg_cancel/ terminate_backend? That seems a bit unclean to me since
> pg_cancel_backend & pg_cancel_backend does not access to the
> procNumber to check the type of the
Andrei Lepikhov writes:
> On 9/4/2024 09:12, Tom Lane wrote:
>> I have another one that I'm not terribly happy about:
>> Author: Alexander Korotkov
>> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
>> Transform OR clauses to ANY expression
>> * What the medical community would call off
On 09.04.24 00:58, Michael Paquier wrote:
That's more linked to the fact that I was going silent without a
laptop for a few weeks before the end of the release cycle, and a way
to say to not count on me, while I was trying to keep my room clean to
avoid noise for others who would rush patches. I
On Mon, Apr 08, 2024 at 04:31:05PM +0900, Kyotaro Horiguchi wrote:
>> diff --git a/src/bin/pg_combinebackup/pg_combinebackup.c
>> b/src/bin/pg_combinebackup/pg_combinebackup.c
>> index 1b07ca3fb6..2788c78fdd 100644
>> +++ b/src/bin/pg_combinebackup/pg_combinebackup.c
> +++ b/src/bin/pg_walsummary/
On Fri, Apr 05, 2024 at 05:18:51PM -0400, Tom Lane wrote:
> Based on this info, I'm disinclined to put work into trying to
> make the case behave correctly with that old libedit version, or
> even to lobotomize the test case enough so it would pass.
By the way, are you planning to do something lik
> On 24 Mar 2024, at 23:34, Nathan Bossart wrote:
>
> Committed that part.
Hi Nathan and Yurii!
Can I ask you please to help me with determining status of CF item [0]. Is it
committed or there's something to move to next CF?
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.p
> On 8 Apr 2024, at 08:17, Bharath Rupireddy
> wrote:
Hi Bharath!
As far as I understand CF entry [0] is committed? I understand that there are
some open followups, but I just want to determine correct CF item status...
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.postgr
On Fri, Apr 05, 2024 at 06:22:58AM +, Hayato Kuroda (Fujitsu) wrote:
> Thanks for pointing out. Yes, we fixed a behavior by the commit aa5edbe37,
> but we missed the redo case. I made a fix patch based on the suggestion [1].
+ boolmod_buf = false;
Perhaps you could name that mod
101 - 140 of 140 matches
Mail list logo
