On 30/03/2025 14:32, Heikki Linnakangas wrote:
On 30/03/2025 13:28, Etsuro Fujita wrote:
Another thing I noticed is $SUBJECT: I think “if lock could not
immediately acquired” should be “if lock could not be immediately
acquired”. Attached is a patch for that.
Yep. And there are more instances
On 30/03/2025 13:23, Etsuro Fujita wrote:
While working on something else I noticed $SUBJECT: we are allocating
more memory than necessary and copying more data than necessary
because we specify the wrong PgStat_KindInfo member as the size
argument for MemoryContextAlloc and memcpy. This could b
Etsuro Fujita 于2025年3月30日周日 18:28写道：
> Another thing I noticed is $SUBJECT: I think “if lock could not
> immediately acquired” should be “if lock could not be immediately
> acquired”. Attached is a patch for that.
>
Agree.
The patch looks good to me.
--
Thanks,
Tender Wang
On 3/30/25 06:04, Tom Lane wrote:
> Tomas Vondra writes:
>> I've pushed all the parts of this patch series, except for the stress
>> test - which I think was not meant for commit.
>> buildfarm seems happy so far, except for a minor indentation issue
>> (forgot to reindent after merging the separat
On Sun, Mar 30, 2025 at 9:14 AM vignesh C wrote:
>
> On Sat, 29 Mar 2025 at 12:08, jian he wrote:
> >
> >
> > I consolidated it into a new function: CopyThisRelTo.
>
> Few comments:
> 1) Here the error message is not correct, we are printing the original
> table from where copy was done which is
On 2025-03-29 Sa 1:17 AM, Mahendra Singh Thalor wrote:
On Sat, 29 Mar 2025 at 03:50, Andrew Dunstan wrote:
On 2025-03-27 Th 5:15 PM, Andrew Dunstan wrote:
On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote:
On Wed, 12 Mar 2025 at 21:18, Andrew Dunstan
wrote:
On 2025-03-12 We 3:03 AM, j
On Thu, Mar 27, 2025 at 1:25 PM Ashutosh Bapat
wrote:
> On Tue, Mar 25, 2025 at 4:01 PM Etsuro Fujita wrote:
> > In the patch I also fixed a bug; I trusted XactReadOnly to see if the
> > local transaction is READ ONLY, but I noticed that that is not 100%
> > correct, because a transaction which s
While working on something else I noticed $SUBJECT: we are allocating
more memory than necessary and copying more data than necessary
because we specify the wrong PgStat_KindInfo member as the size
argument for MemoryContextAlloc and memcpy. This could become
problematic if snapshotting a very lar
Please see attached a few minor edits to README.tuplock, which I feel
make an improvement over the current version.
Reading through that, though, I could not see a functional difference
between FOR NO KEY UPDATE and FOR KEY SHARE mode of locks. I understand
they are of different strength, exclusiv
Hello hackers,
A couple of buildfarm failures produced by skink, which runs
tests under Valgrind: [1], [2], with the following diagnostics:
31/324 postgresql:recovery / recovery/026_overwrite_contrecord ERROR 325.72s (exit status 255 or signal
127 SIGinvalid)
# Initializing node
Hi
> We get substantial wins on all of fx, fx3, fx4. fx2 is the
> case that gets inlined and never reaches functions.c, so the
> lack of change there is expected. What I found odd is that
> I saw a small speedup (~6%) on fx5 and fx6; those functions
> are in plpgsql so they really shouldn't cha
On Sun Mar 30, 2025 at 4:39 AM PDT, Heikki Linnakangas wrote:
> On 30/03/2025 14:32, Heikki Linnakangas wrote:
>> On 30/03/2025 13:28, Etsuro Fujita wrote:
>>> Another thing I noticed is $SUBJECT: I think “if lock could not
>>> immediately acquired” should be “if lock could not be immediately
>>> a
On 30/03/2025 13:28, Etsuro Fujita wrote:
Another thing I noticed is $SUBJECT: I think “if lock could not
immediately acquired” should be “if lock could not be immediately
acquired”. Attached is a patch for that.
Yep. And there are more instances of the same typo in other such
flush_cb functi
On Tue, Mar 18, 2025 at 5:56 AM Andres Freund wrote:
> So one thing is that the pin count differs by 1 at the start of the scan. No
> idea why.
>
> I still don't know what drives the difference between freebsd and the rest,
> but IIUC the reason this fails is just that we are holding too many buff
On Tue, Mar 25, 2025 at 11:58 AM Andres Freund wrote:
>
> > Another thought on complete_shared running on other backends: I wonder if we
> > should push an ErrorContextCallback that adds "CONTEXT: completing I/O of
> > other process" or similar, so people wonder less about how "SELECT FROM a"
> >
On Sat, Mar 29, 2025 at 7:09 PM Andres Freund wrote:
> Hi,
>
> On 2025-03-29 13:17:44 -0400, Andres Freund wrote:
> > On 2025-03-28 13:47:16 -0400, Andres Freund wrote:
> > > Attached is a fix for the issue.
> >
> > I plan to push this fix soon, unless somebody protests...
>
> And done.
>
Hi!
S
On 2025-03-30 Su 12:50 PM, Andrew Dunstan wrote:
On 2025-03-29 Sa 1:17 AM, Mahendra Singh Thalor wrote:
On Sat, 29 Mar 2025 at 03:50, Andrew Dunstan
wrote:
On 2025-03-27 Th 5:15 PM, Andrew Dunstan wrote:
On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote:
On Wed, 12 Mar 2025 at 21:18,
On Mon, 24 Mar 2025 at 10:07, vignesh C wrote:
>
> On Mon, 17 Mar 2025 at 09:26, vignesh C wrote:
>
Here's a quick commitfest status report as of today:
status | start | 10th | 17th | 24th | 31st
+-+---+---++--
On 31.03.2025 06:33, David Rowley wrote:
On Mon, 31 Mar 2025 at 16:21, Alena Rybakina wrote:
However, is it necessary to check that extra->inner_unique must be false for
SEMI/ANTI joins here, or am I missing something? It looks a little confusing at
this point.
If it is necessary, I don't se
I spent some time looking at the v17 patchset. There were some pretty
strange things in it --- why were some of the variants of array_sort()
marked as volatile, for example? But the two things I'd like to
suggest functionality-wise are:
* The second argument of the variants with booleans should
Hi,
On 2025-03-27 10:52:10 +1300, Thomas Munro wrote:
> On Thu, Mar 27, 2025 at 10:41 AM Andres Freund wrote:
> > > > Subject: [PATCH v2.12 13/28] Enable IO concurrency on all systems
> > >
> > > Consider also updating this comment to stop focusing on prefetch; I think
> > > changing that aligns
Hi,
On 2025-03-29 14:29:29 -0700, Noah Misch wrote:
> > Subject: [PATCH v2.14 11/29] Let caller of PageIsVerified() control
> > ignore_checksum_failure
> > Subject: [PATCH v2.14 12/29] bufmgr: Use AIO in StartReadBuffers()
> > Subject: [PATCH v2.14 14/29] aio: Basic read_stream adjustments for re
Hi,
I found that comments in trigger.c describing fields of three different
structures in a comment block. I feel this is confusing because some
structure names are not explicitly mentioned there even though common field
names are used between structures. I've attached a patch to improve the comme
On 3/31/25 02:23, torikoshia wrote:
On Fri, Mar 7, 2025 at 6:43 AM Rafael Thofehrn Castro
Implemented this version. New patch has the following characteristics:
I haven't looked into the code yet, but when I ran below commands during
make installcheck, there was an error and an assertion fai
Hi, Alena!
On Sat, Mar 29, 2025 at 9:03 PM Alena Rybakina
wrote:
> On 29.03.2025 14:03, Alexander Korotkov wrote:
>> One thing I have to fix: we must do
>> IncrementVarSublevelsUp() unconditionally for all expressions as Vars
>> could be deeper inside.
>
> Yes, I'm looking at it too, I've just un
Another thing I noticed is $SUBJECT: I think “if lock could not
immediately acquired” should be “if lock could not be immediately
acquired”. Attached is a patch for that.
Best regards,
Etsuro Fujita
fix-typo-in-comment.patch
Description: Binary data
Hi!
On 21.03.2025 18:56, Andrei Lepikhov wrote:
On 20/3/2025 07:02, David Rowley wrote:
On Thu, 20 Mar 2025 at 06:16, Andrei Lepikhov wrote:
How can we be sure that semi or anti-join needs only one tuple? I think
it would be enough to control the absence of join clauses and
filters in
the j
On Mon, 31 Mar 2025 at 16:21, Alena Rybakina wrote:
> However, is it necessary to check that extra->inner_unique must be false for
> SEMI/ANTI joins here, or am I missing something? It looks a little confusing
> at this point.
If it is necessary, I don't see the reason for it. It was me that
wo
On 2025/03/28 0:13, torikoshia wrote:
On 2025-03-27 11:06, torikoshia wrote:
Hi,
I had another off-list discussion with Fujii-san, and according to the
following manual[1], it seems that a transaction with an overflowed
subtransaction is already considered inconsistent:
Reaching a consiste
Hello Ashutosh,
Thank you for your detailed review, and apologies for my delayed response.
On Thu, Mar 27, 2025 at 1:42 PM Ashutosh Bapat
wrote:
>
> Here are memory consumption numbers using list_free() instead of pfree(),
> using the same method as [1], using a binary without asserts and debug
On Sun, Mar 30, 2025 at 4:31 AM Heikki Linnakangas wrote:
>
> On 30/03/2025 13:23, Etsuro Fujita wrote:
> > While working on something else I noticed $SUBJECT: we are allocating
> > more memory than necessary and copying more data than necessary
> > because we specify the wrong PgStat_KindInfo mem
On 31.03.2025 06:04, David Rowley wrote:
On Mon, 31 Mar 2025 at 15:33, Alena Rybakina wrote:
I believe it's worth asserting that both inner_unique and single_mode are not
true at the same time — just as a safety check.
add_paths_to_joinrel() just chooses not to populate inner_unique for
SEMI
Hi Tomas,
>
> Right. I'm still not convinced if this makes any difference, or whether
> this alignment was merely a consequence of using ShmemAlloc(). I don't
> want to make this harder to understand unnecessarily.
>
Yeah, it makes sense.
> Let's keep this simple - without additional alignment
On Mon, 31 Mar 2025 at 15:33, Alena Rybakina wrote:
> I believe it's worth asserting that both inner_unique and single_mode are not
> true at the same time — just as a safety check.
add_paths_to_joinrel() just chooses not to populate inner_unique for
SEMI and ANTI joins because, as of today's ma
34 matches
Mail list logo
