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
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
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 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
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
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
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 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
+-+---+---++--
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 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,
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,
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 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
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
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 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
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 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 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 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 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 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 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 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 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
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 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
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
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
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
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
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
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
34 matches
Mail list logo
