On 13/06/2025 11:20 pm, Andres Freund wrote:
Attached is a patch that fixes the problem for me. Alexander, Konstantin,
could you verify that it also fixes the problem for you?
Given that it does address the problem for me, I'm inclined to push this
fairly soon, the barrier is pretty obviously r
On Sun, Jun 15, 2025 at 12:00 PM Alexander Lakhin wrote:
>
> Hello Alexander,
>
> 10.06.2025 23:14, Alexander Korotkov wrote:
>
> So, my proposal is to commit the attached patchset to the HEAD, and
> commit [1] to the back branches. Any objections?
>
>
> As the buildfarm animal prion shows [1], t
On Tue, Jun 10, 2025 at 4:30 PM Michael Paquier wrote:
>
> On Mon, Jun 09, 2025 at 10:25:26PM +0900, Ryo Kanbayashi wrote:
> >> This could be a patch built on top of the introduction of the core API
> >> for the service file.
> >
> > :)
>
> >> - Perhaps a shortcut for PROMPT?
> >
> > I will kindly
Hi
ne 8. 6. 2025 v 6:25 odesílatel Pavel Stehule
napsal:
> Hi
>
> I started reviewing this patch.
>
>
> so 7. 6. 2025 v 18:41 odesílatel Tom Lane napsal:
>
>> This is a rather delayed response to the discussion of bug
>> #18693 [1], in which I wrote:
>>
>> > (It's kind of annoying that "strict"
Hi Arseniy!
Thanks for finding these problems.
I had several attempts to wrap my head around original patch with fixes, but
when it was broken into several steps it finally became easier for me.
Here are some thought about patches.
> On 10 Jun 2025, at 13:18, Arseniy Mukhin wrote:
> <0001-a
15.06.2025 14:02, Alexander Korotkov wrote:
Could you, please, check this patch? On my system it makes 046 and
047 execute in 140 secs with -O0 and -DRELCACHE_FORCE_RELEASE
-DCATCACHE_FORCE_RELEASE.
Thank you for the patch!
It decreases the test's duration significantly:
# +++ tap check in sr
Hi, everyone
I am writing to ask if the recently introduced RWF_DONTCACHE [0] (originally
named RWF_UNCACHE) in the Linux kernel will be or is already supported by
PostgreSQL?
I am not sure if RWF_DONTCACHE will improve PostgreSQL performance. In fact, I
think it may even degrade performance.
BTW, while you're cleaning up this commit, could you remove the
excess newlines in some of the "note" commands in 046 and 047, like
note('starting checkpoint\n');
This produces bizarre output, as shown in the buildfarm logs:
[04:04:38.953](603.550s) # starting checkpoint\\n
With this two additional changes:
diff --git a/src/backend/storage/aio/aio.c b/src/backend/storage/aio/aio.c
index 6c6c0a908e2..6dd2816bea9 100644
--- a/src/backend/storage/aio/aio.c
+++ b/src/backend/storage/aio/aio.c
@@ -538,6 +538,9 @@ pgaio_io_process_completion(PgAioHandle *ioh, int
result)
Hi,
Attached is v2 of the patch to add threshold-based sleep to
XactLockTableWait functions.
Changes from v1:
- Simplified approach based on Fujii's feedback [1]: instead of exponential
backoff,
we now sleep 1ms for the first 5 seconds, then switch directly to 1s
sleeps
- Reduced the threshold
On 12.06.25 17:28, Alvaro Herrera wrote:
On 2025-Jun-12, Peter Eisentraut wrote:
This new code uses the term "TLS" where the rest of PostgreSQL, including
the rest of psql, uses the term "SSL". Making this different seems
uselessly confusing. I suggest the attached patch to use "SSL" here as
Hello Alexander,
10.06.2025 23:14, Alexander Korotkov wrote:
So, my proposal is to commit the attached patchset to the HEAD, and
commit [1] to the back branches. Any objections?
As the buildfarm animal prion shows [1], the 046_checkpoint_logical_slot
test fails with "-DRELCACHE_FORCE_RELEASE
Hi, Alexander!
On Sun, Jun 15, 2025 at 12:00 PM Alexander Lakhin wrote:
>
> Hello Alexander,
>
> 10.06.2025 23:14, Alexander Korotkov wrote:
>
> So, my proposal is to commit the attached patchset to the HEAD, and
> commit [1] to the back branches. Any objections?
>
>
> As the buildfarm animal pr
On Sun, Jun 15, 2025 at 4:24 PM Andrey Borodin wrote:
>
>
> Hi Arseniy!
>
> Thanks for finding these problems.
> I had several attempts to wrap my head around original patch with fixes, but
> when it was broken into several steps it finally became easier for me.
> Here are some thought about patc
Hi, Tom!
On Sun, Jun 15, 2025 at 7:05 PM Tom Lane wrote:
> BTW, while you're cleaning up this commit, could you remove the
> excess newlines in some of the "note" commands in 046 and 047, like
>
> note('starting checkpoint\n');
>
> This produces bizarre output, as shown in the buildfarm logs:
Th
2025년 6월 14일 (토) 오전 6:50, Nathan Bossart 님이 작성:
> I suspect detaching/destroying segments would be applicable elsewhere, I'm
> just not sure about providing something with the aforementioned behavior.
>
> Could your use-case be handled with a DSA? On the other thread [0], we're
> talking about add
On Wed, 11 Jun 2025 at 20:37, Tatsuro Yamada wrote:
> I created a regression test to check the enable_groupagg parameter in
> the new patch.
> To ensure plan stability, I disabled parallel query by setting the
> max_parallel_*
> parameters to 0.
>
> Any feedback is welcome.
Typically, in the reg
On Sun, Jun 15, 2025 at 8:32 AM Andy Fan wrote:
>
> Jesper Pedersen writes:
>
> Hi,
>
> Thank you Nathan, Tomas and Jesper for the answers. The patch at [0]
> works for me and I could work with master smoothly now.
Pushed, thanks for testing! I'll do some more testing to see what
versions/levels
Hi all,
While looking at the heap code, I've found that relrewrite, parameter
used a trick to keep a link to the original relation rewritten, is not
documented at the top of heap_create_with_catalog() contrary to all
its other parameters.
A simple patch is attached to document that.
Thanks,
--
M
I think we need to do something slightly earlier than that. Attached is
what I propose.
I agree, my patch could miss one case with undefined $$stderr.
Fixed my patch with your suggestion
I think the short answer is no, we've already hijacked STDOUT/STDERR in
Utils.pm to point to the log file,
Rebased and attached v3, which fixes compilation on mingw32.
On Tue, 10 Jun 2025, Dimitrios Apostolou wrote:
Rebased and attached new patch. Should I add it to July's commitfest?
On Fri, 4 Apr 2025, Dimitrios Apostolou wrote:
Hello list,
based on the delays I experienced in pg_restore, a
Attaching files now...
On Mon, 16 Jun 2025, Dimitrios Apostolou wrote:
Attaching v3 of the patch, together with a new test file that tests
previously untested flags of pg_restore.
Added to July's commitfest:
https://commitfest.postgresql.org/patch/5821/
On Thu, 12 Jun 2025, Dimitrios Apostol
Attaching v3 of the patch, together with a new test file that tests
previously untested flags of pg_restore.
Added to July's commitfest:
https://commitfest.postgresql.org/patch/5821/
On Thu, 12 Jun 2025, Dimitrios Apostolou wrote:
I wonder about the following in pg_restore.c.
Right now my impl
On Sat, Jun 14, 2025 at 11:37 PM Dilip Kumar wrote:
>
> On Fri, May 30, 2025 at 3:38 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wed, May 28, 2025 at 2:09 AM Masahiko Sawada wrote:
> > >
> > > On Fri, May 23, 2025 at 10:07 PM Amit Kapila
> > >
> > > wrote:
> > > >
> > > > In the case presented h
On Sat, Jun 14, 2025 at 11:08 AM Amit Kapila wrote:
> > I feel WARNING and CAUTION markups could be a little strong for the
> > concerned case. Such markups are generally used when there is a
> > side-effect involved with the usage. But in our case, there is no such
> > side-effect with the API.
hi.
static void checkPartition(Relation rel, Oid partRelOid)
function name checkPartition is not ideal, maybe we can change it to
CheckPartitionForMerge or MergePartitionCheck.
(attached v45-002 is error message refactoring for checkPartition,
I didn't change the name though.)
For the command:
A
26 matches
Mail list logo
