Hi, Michael!
On Wed, Feb 26, 2025 at 3:04 AM Michael Paquier wrote:
>
> On Tue, Feb 25, 2025 at 05:19:29PM +0200, Alexander Korotkov wrote:
> > It seems that I managed to reproduce the issue on my Raspberry PI 4.
> > After running our test suite in a loop for 2 days I found one timeout.
>
> Hmm.
> On 25 Feb 2025, at 20:19, Alexander Korotkov wrote:
>
>
Hi!
One little piece of code looks suspicious to me. But I was not raising concern
because I see similar code everywhere in the codebase. But know Kirill asked to
me explain what is going on and I cannot.
This seems to be relevan
On Tue, Feb 25, 2025 at 05:19:29PM +0200, Alexander Korotkov wrote:
> It seems that I managed to reproduce the issue on my Raspberry PI 4.
> After running our test suite in a loop for 2 days I found one timeout.
Hmm. It's surprising to not see a higher occurence. My buildfarm
host has caught tha
On Tue, Feb 18, 2025 at 2:29 AM Alexander Korotkov wrote:
>
> On Tue, Feb 18, 2025 at 2:21 AM Michael Paquier wrote:
> >
> > On Mon, Feb 17, 2025 at 11:25:05AM -0500, Tom Lane wrote:
> > > This timeout failure on hachi looks suspicious as well:
> > >
> > > https://buildfarm.postgresql.org/cgi-bin
On Tue, Feb 18, 2025 at 2:21 AM Michael Paquier wrote:
>
> On Mon, Feb 17, 2025 at 11:25:05AM -0500, Tom Lane wrote:
> > This timeout failure on hachi looks suspicious as well:
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hachi&dt=2025-02-17%2003%3A05%3A03
> >
> > Might be relev
On Mon, Feb 17, 2025 at 11:25:05AM -0500, Tom Lane wrote:
> This timeout failure on hachi looks suspicious as well:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hachi&dt=2025-02-17%2003%3A05%3A03
>
> Might be relevant that they are both aarch64?
Just logged into the host. The log
Oops, I send wrong patch as a fix.
The right one is attached.
Pavel
On Mon, 17 Feb 2025 at 13:40, Pavel Borisov wrote:
>
> Hi, Kirill!
> Per your report, I revised the comment to fix typos. Also some little
> changes in grammar.
>
> Kind regards,
> Pavel Borisov
v2-0001-Fix-typo-and-grammar-in
Alexander Korotkov writes:
> I've spotted the failure on the buildfarm.
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=batta&dt=2025-02-17%2008%3A05%3A03
> I can't quickly guess the reason. I'm going to revert patch for now,
> then we investigate
This timeout failure on hachi looks su
Hi, Victor!
On Mon, 17 Feb 2025 at 12:47, Victor Yegorov wrote:
>
> Hey.
>
> I find “Get rid of WALBufMappingLock" commit message misleading, 'cos Lock
> it's being replaced by CV, actually.
>
> Should the subject be changed to “Replace WALBufMappingLock with
On Mon, Feb 17, 2025 at 11:44 AM Pavel Borisov wrote:
> Oops, I send wrong patch as a fix.
> The right one is attached.
>
> Pavel
I've spotted the failure on the buildfarm.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=batta&dt=2025-02-17%2008%3A05%3A03
I can't quickly guess the reason.
Hi, Kirill!
Per your report, I revised the comment to fix typos. Also some little
changes in grammar.
Kind regards,
Pavel Borisov
0001-Fix-typo-and-grammar-in-comment-introduced-by-6a2275.patch
Description: Binary data
On Mon, 17 Feb 2025 at 13:20, Pavel Borisov wrote:
>
> Hi, Victor!
>
> On Mon, 17 Feb 2025 at 12:47, Victor Yegorov wrote:
> >
> > Hey.
> >
> > I find “Get rid of WALBufMappingLock" commit message misleading, 'cos Lock
> > it's bein
Hey.
I find “Get rid of WALBufMappingLock" commit message misleading, 'cos Lock
it's being replaced by CV, actually.
Should the subject be changed to “Replace WALBufMappingLock with
ConditionVariable” instead?
--
Victor Yegorov
Hi!
I spotted a typo in v10:
+ /*
+ * Page at nextidx wasn't initialized yet, so we cann't move
+ * InitializedUpto further. It will be moved by backend which
+ * will initialize nextidx.
+ */
cann't - > can't
moved by backend -> moved by the backend
--
Best regards,
Kirill Reshke
Hi!
On Fri, Feb 14, 2025 at 4:11 PM Yura Sokolov wrote:
> 14.02.2025 17:09, Yura Sokolov пишет:
> > 14.02.2025 13:24, Alexander Korotkov пишет:
> >> On Fri, Feb 14, 2025 at 11:45 AM Pavel Borisov
> >> wrote:
> >>> On Fri, 14 Feb 2025 at 00:59, Alexander Korotkov
> >>> wrote:
> On Thu, Fe
;>>>
>>>> Oh, sorry, I really did wrong. I've done git format-patch for wrong
>>>> local branch for v5 and v6. Patches I've sent for v5 and v6 are
>>>> actually the same as my v1. This is really pity. Please, find the
>>>> right version of patchset att
d v6. Patches I've sent for v5 and v6 are
>>> actually the same as my v1. This is really pity. Please, find the
>>> right version of patchset attached.
>>
>> I've rechecked v7. In v6 a proposal from [1] was not reflected. Now it
>> landed in v7.
>&
On Fri, Feb 14, 2025 at 11:45 AM Pavel Borisov wrote:
> On Fri, 14 Feb 2025 at 00:59, Alexander Korotkov wrote:
> > On Thu, Feb 13, 2025 at 6:39 PM Pavel Borisov
> > wrote:
> > > On Thu, 13 Feb 2025 at 14:08, Alexander Korotkov
> > > wrote:
> > > >
> > > > On Thu, Feb 13, 2025 at 11:45 AM Yur
Hi, Alexander!
On Fri, 14 Feb 2025 at 00:59, Alexander Korotkov wrote:
>
> Hi, Pavel!
>
> On Thu, Feb 13, 2025 at 6:39 PM Pavel Borisov wrote:
> > On Thu, 13 Feb 2025 at 14:08, Alexander Korotkov
> > wrote:
> > >
> > > On Thu, Feb 13, 2025 at 11:45 AM Yura Sokolov
> > > wrote:
> > > > 13.02.
Hi, Pavel!
On Thu, Feb 13, 2025 at 6:39 PM Pavel Borisov wrote:
> On Thu, 13 Feb 2025 at 14:08, Alexander Korotkov wrote:
> >
> > On Thu, Feb 13, 2025 at 11:45 AM Yura Sokolov
> > wrote:
> > > 13.02.2025 12:34, Alexander Korotkov пишет:
> > > > On Wed, Feb 12, 2025 at 8:16 PM Yura Sokolov
>
Hi, Yura and Alexander!
On Thu, 13 Feb 2025 at 14:08, Alexander Korotkov wrote:
>
> On Thu, Feb 13, 2025 at 11:45 AM Yura Sokolov
> wrote:
> > 13.02.2025 12:34, Alexander Korotkov пишет:
> > > On Wed, Feb 12, 2025 at 8:16 PM Yura Sokolov
> > > wrote:
> > >> 08.02.2025 13:07, Alexander Korotko
On Thu, Feb 13, 2025 at 11:45 AM Yura Sokolov wrote:
> 13.02.2025 12:34, Alexander Korotkov пишет:
> > On Wed, Feb 12, 2025 at 8:16 PM Yura Sokolov
> > wrote:
> >> 08.02.2025 13:07, Alexander Korotkov пишет:
> >>> On Fri, Feb 7, 2025 at 1:39 PM Alexander Korotkov
> >>> wrote:
> Good, than
13.02.2025 12:34, Alexander Korotkov пишет:
> On Wed, Feb 12, 2025 at 8:16 PM Yura Sokolov wrote:
>> 08.02.2025 13:07, Alexander Korotkov пишет:
>>> On Fri, Feb 7, 2025 at 1:39 PM Alexander Korotkov
>>> wrote:
Good, thank you. I think 0001 patch is generally good, but needs some
furth
On Wed, Feb 12, 2025 at 8:16 PM Yura Sokolov wrote:
> 08.02.2025 13:07, Alexander Korotkov пишет:
> > On Fri, Feb 7, 2025 at 1:39 PM Alexander Korotkov
> > wrote:
> >> Good, thank you. I think 0001 patch is generally good, but needs some
> >> further polishing, e.g. more comments explaining how
-b3d4-67ff9a00d447%40postgrespro.ru
---
regards
Yura Sokolov aka funny-falconFrom d243176a52faf6a57edd5719cfcbe8b3d1bbb919 Mon Sep 17 00:00:00 2001
From: Yura Sokolov
Date: Sat, 18 Jan 2025 23:50:09 +0300
Subject: [PATCH v4 1/2] Get rid of WALBufMappingLock
Allow many backends to concurrently initi
On Fri, Feb 7, 2025 at 1:39 PM Alexander Korotkov wrote:
> Good, thank you. I think 0001 patch is generally good, but needs some
> further polishing, e.g. more comments explaining how does it work.
Two things comes to my mind worth rechecking about 0001.
1) Are XLogCtl->InitializeReserved, XLogC
On Fri, Feb 7, 2025 at 1:24 PM Yura Sokolov wrote:
> 07.02.2025 14:02, Yura Sokolov пишет:
> > 07.02.2025 01:26, Alexander Korotkov пишет:
> >> Hi!
> >>
> >> On Sun, Jan 19, 2025 at 2:11 AM Yura Sokolov
> >> wrote:
> >>>
> >>> During discussion of Increasing NUM_XLOGINSERT_LOCKS [1], Andres Freu
ched.
>
> I've changed condition for broadcast a bit ("less" instead "not equal"):
> - buffer's border may already go into future,
> - and then other backend will reach not yet initialized buffer and will
> broadcast.
2. I've inserted abort if &q
nd clearer, I agree to keep
just single condition variable.
Cleaned version is attached.
I've changed condition for broadcast a bit ("less" instead "not equal"):
- buffer's border may already go into future,
- and then other backend will reach not yet initialized buff
Hi!
On Sun, Jan 19, 2025 at 2:11 AM Yura Sokolov wrote:
>
> During discussion of Increasing NUM_XLOGINSERT_LOCKS [1], Andres Freund
> used benchmark which creates WAL records very intensively. While I this
> it is not completely fair (1MB log records are really rare), it pushed
> me to analyze wr
19.01.2025 03:11, Yura Sokolov пишет:
Good day, hackers.
During discussion of Increasing NUM_XLOGINSERT_LOCKS [1], Andres Freund
used benchmark which creates WAL records very intensively. While I this
it is not completely fair (1MB log records are really rare), it pushed
me to analyze write-s
27 /2133
So, patched version with increased NUM_XLOGINSERT_LOCKS looks no worse
than unpatched without increasing num of locks.
---
regards
Yura Sokolov aka funny-falconFrom 236b69ae1f524c7e8488da7244966e631324a0e3 Mon Sep 17 00:00:00 2001
From: Yura Sokolov
Date: Sat, 18 Jan 2025
32 matches
Mail list logo
