On Thu, 2025-03-20 at 08:45 -0400, Robert Haas wrote:
> * When the collation/ctype/whatever definitions upon which you are
> relying change, you can either decide to switch to the new ones
> without rebuilding your indexes and risk wrong results until you
> reindex, or you can decide to create new
On 2025-Mar-21, Ashutosh Bapat wrote:
> I used the same parallelism in pg_restore and pg_dump too. And your
> numbers seem to be similar to mine; slightly less than 20% slowdown.
> But is that slowdown acceptable? From the earlier discussions, it
> seems the answer is No. Haven't heard otherwise.
On Friday, March 21, 2025, Masahiko Sawada wrote:
> On Fri, Mar 21, 2025 at 5:32 PM David G. Johnston
> wrote:
> >
> > On Tue, Mar 18, 2025 at 7:56 PM Sutou Kouhei wrote:
> >>
> >> Hi,
> >>
> >> In
> >> "Re: Make COPY format extendable: Extract COPY TO format
> implementations" on Mon, 17 Ma
On Fri, Mar 21, 2025 at 5:32 PM David G. Johnston
wrote:
>
> On Tue, Mar 18, 2025 at 7:56 PM Sutou Kouhei wrote:
>>
>> Hi,
>>
>> In
>> "Re: Make COPY format extendable: Extract COPY TO format implementations"
>> on Mon, 17 Mar 2025 13:50:03 -0700,
>> Masahiko Sawada wrote:
>>
>> > I think
On Fri, Mar 21, 2025 at 2:27 PM Jeff Davis wrote:
> > Those who are now trying to make the builtin collation provider have
> > properties that it does not have and was not intended to have when it
> > was added, they would need to arrange the work to make it have those
> > properties if they want
I've been preparing these for commit, and I've attached what I have so far.
A few notes:
* 0001 just renames the TRY_POPCNT_FAST macro to indicate that it's
x86_64-specific. IMO this is worth doing indpendent of this patch set,
but it's more important with the patch set since we need somethin
On Fri, 2025-03-21 at 14:54 -0400, Robert Haas wrote:
> And nobody has refuted the argument that refusing to
> update the Unicode tables will cause other problems (such as not
> knowing what to do with new code points that are added in the other
> places where those tables are used).
The argument
Sami Imseih writes:
> overall this LGTM, and I don't really have other comments.
I took a look through v8, and have just a couple of trivial nits:
+static void overexplain_debug_handler(ExplainState *, DefElem *,
+ ParseState *);
+static void overexplain_rang
On Tue, Mar 18, 2025 at 7:56 PM Sutou Kouhei wrote:
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format
> implementations" on Mon, 17 Mar 2025 13:50:03 -0700,
> Masahiko Sawada wrote:
>
> > I think that built-in formats also need to have their handler
> > functions. This
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi Aleksander,
your patch looks good to me.
Changing status
On Thu, Mar 20, 2025 at 2:31 PM Nathan Bossart
wrote:
> On Thu, Mar 20, 2025 at 02:18:33PM -0700, David G. Johnston wrote:
> > So my concern about dump/restore seems to be alleviated but then, why can
> > we not just do whatever pg_dump is doing to decide whether the current
> > value for vacuum_
On Fri, Mar 21, 2025 at 05:26:20PM +0100, Christoph Berg wrote:
> Just one minor thing, I don't understand what you are trying to say in
> this comment:
>
>> +/*
>> + * Note that the argument types are enforced for the per-field custom
>> + * functions.
>> + */
>> +#define JUMBLE_CUSTOM(nodetype,
On Fri, Mar 21, 2025 at 11:52 AM Tom Lane wrote:
> I think this is completely wrong and should be reverted. There
> cannot be a Param there, and if there were it would not represent
> a reference to the Gather's child.
>
> I tried reverting this code change, and check-world still passes,
> with o
On Mar 21, 2025, at 17:52, Matheus Alcantara wrote:
> Did you miss to attach the patch?
No. You can see it in the archive[1]. Direct link[2].
> Maybe we could make the "extension" part of the extension control path
> explicitly, like Peter has mentioned in his first patch version [1]?.
> If "d
Hi.
Em sáb., 15 de fev. de 2025 às 06:20, Alexander Korotkov <
aekorot...@gmail.com> escreveu:
> On Thu, Feb 13, 2025 at 1:00 AM Alexander Korotkov
> wrote:
> >
> > On Tue, Feb 11, 2025 at 5:31 PM Alena Rybakina
> > wrote:
> > > Hi! Thank you for the work with this subject, I think it is really
> On 21 Mar 2025, at 21:55, Andres Freund wrote:
> 1) When are we supposed to use IDK and when not? We seem to
> be extremely inconsistent. E.g.
> git grep -P 'WAL(?=\ 42
> git grep -P 'WAL(?!\ 904
>
> Given that, at least for html, doesn't change the display, that's
> perhaps not
Hi David, thanks for testing!
On Wed, Mar 19, 2025 at 2:29 PM David E. Wheeler wrote:
>
> First thing I notice is that prefix= uses the magic to insert
> “postgresql” into the path if it’s not already there:
>
> ``` console
> ❯ make PG_CONFIG=~/dev/c/postgres/pgsql-devel/bin/pg_config
> prefix=/
Hi Kuroda-san,
On Fri, Mar 21, 2025 at 12:28:10PM +, Hayato Kuroda (Fujitsu) wrote:
> I'm also working on the thread to resolve the random failure.
Thanks for looking at it!
> I've also tried the idea with the living transaction via background_psql(),
> but I got the same result. The test co
Hi,
I was trying to write some docs for an AIO related view. As part of that I
noticed that we referenced I/O a lot, but never defined it as an acronym or
had it in the glossary. While adding those I got somewhat confused by things
that have confused me in the past:
1) When are we supposed to us
On Fri, 2025-03-21 at 10:45 -0400, Robert Haas wrote:
> We might need a way for ALTER DATABASE to allow the
> database default to be adjusted. I'm not quite sure here, but my
> general feeling is that Unicode version feels like part of the
> collation and that we should avoid introducing a separate
On Fri, Mar 21, 2025 at 8:19 AM Andrey Borodin wrote:
>
> > On 21 Mar 2025, at 05:54, Melanie Plageman
> > wrote:
> >
> > I also think it is worth making a btree directory in src/test instead
> > of adding this to src/test/modules/test_misc. In fact it might be
> > worth moving the gin and brin
Robert Haas writes:
> However, I'm a bit concerned about the overall premise of the patch
> set. It feels like it is moving something that really ought to happen
> at optimization time back to parse time. I have a feeling that's going
> to break something, although I am not sure right now exactly
Robert Haas writes:
> I'm happy to have you tidy up here in whatever way seems best to you.
Cool, done.
regards, tom lane
On Fri, Mar 21, 2025 at 2:37 PM Tom Lane wrote:
> I took a look through v8, and have just a couple of trivial nits:
Thank you!
> +static void overexplain_debug_handler(ExplainState *, DefElem *,
> + ParseState *);
> +static void overexplain_range_table_handle
Sorry, I forgot to provide a link to the problem [0], actually. So I
provided it below.
[0]
https://www.postgresql.org/message-id/CAPpHfduoJEuoixPTTg2tjhnXqrdobuMaQGxriqxJ9TjN1uxOuA%40mail.gmail.com
On 21.03.2025 22:42, Alena Rybakina wrote:
On 13.03.2025 09:42, Bertrand Drouvot wrote:
Hi,
On Fri, Mar 21, 2025 at 1:41 PM Tom Lane wrote:
> (and similarly in fix_upper_expr_mutator). So actually, I had broken
> setrefs.c's matching of Params to lower plan levels with the
> multi-assignment business, and Amit was dodging that breakage.
> But this change is still wrong in itself: if any
I'm a bit confused by what the 'apprelids' field in the Append and
MergeAppend nodes is supposed to be doing. Its contents seem to be ...
kinda random.
1. If a (Merge)Append is generated by partition expansion, then
apprelids ends up being the RTI generated for the parent table. If you
do a partit
On Fri, 2025-03-21 at 17:15 +0100, Peter Eisentraut wrote:
> And we knew at the time the builtin collation
> provider was added that it would have certain problems with the
> Unicode
> table updates, and we accepted it with the understanding that this
> would
> not change our procedures.
Correc
On 2025-Mar-21, Robert Haas wrote:
> I don't agree with this conclusion.
Uhm.
> The 8.3 casting changes were problematic because any piece of SQL
> you'd ever written could have problems.
Okay, this much I agree with.
> This change will only break queries that look at the attnotnull
> column.
> On 21 Mar 2025, at 13:40, Andrew Dunstan wrote:
> On 2025-03-20 Th 7:26 PM, Andres Freund wrote:
>> How about we provide the current libpq.so without linking to curl and also a
>> libpq-oauth.so that has curl support? If we do it right libpq-oauth.so would
>> itself link to libpq.so, making lib
Peter Eisentraut writes:
> I have a few pieces of feedback that could be addressed by additional
> rules for how things are listed in the dashboard:
> - If I'm the committer for a patch but not a reviewer, and the patch is
> in "needs review" status, then the patch is formally speaking not
> a
Robert Haas writes:
> On Fri, Mar 21, 2025 at 11:52 AM Tom Lane wrote:
>> I tried reverting this code change, and check-world still passes,
>> with or without debug_parallel_query = regress. So if there is
>> a case I'm missing, the regression tests don't expose it.
> Did you try the test case
On Fri, Mar 21, 2025 at 2:45 AM Jeff Davis wrote:
> On Thu, 2025-03-20 at 08:45 -0400, Robert Haas wrote:
> > * When the collation/ctype/whatever definitions upon which you are
> > relying change, you can either decide to switch to the new ones
> > without rebuilding your indexes and risk wrong re
Good day, Tomas
14.03.2025 17:30, Tomas Vondra wrote:
>
> Yes, with tmpfs the impact looks much more significant. For 8K the
> speedup is ~1.3x, for 64K it's up to ~2x, for 1M it's ~1.1x.
>
>
> That being said, I wonder how big is the impact for practical workloads.
> ISTM this workload is pret
On 2025-03-21 Fr 11:52 AM, Matheus Alcantara wrote:
On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan wrote:
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that machine, but the report is pretty opaque:
# +
Matheus Alcantara writes:
> On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan wrote:
>>> (wondering if this another of these cases where the "path includes
>>> postgres" thing bites us, and we're looking in the wrong place)
>> Nope, testing shows it's not that, so I am rather confused about what w
On 17.03.25 23:11, Jelte Fennema-Nio wrote:
1. Major change: There's a new /me page which shows a dashboard of
open patches where you are author/reviewer/committer. These patches
are ordered & grouped in a hopefully useful way. Peter Geoghegan
suggested adding a "dashboard" of this kind. It's the
Re: Michael Paquier
> I have been thinking about this patch for a couple of days. What
> makes me unhappy in this proposal is that RangeTblEntry is a large and
> complicated Node, and we only want to force a custom computation for
> the "relid" portion of the node, while being able to also take so
Hi,
On 2025-03-21 14:35:16 +0300, Yura Sokolov wrote:
> From 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001
> From: Yura Sokolov
> Date: Mon, 3 Feb 2025 11:58:33 +0300
> Subject: [PATCH v2] sinvaladt.c: use atomic operations on maxMsgNum
>
> msgnumLock spinlock could be highly
Great, thank you! Looking over v10, I think I've run out of feedback
at this point. Marked Ready for Committer.
--Jacob
On 15.03.25 07:54, Jeremy Schneider wrote:
in favor of leaving it alone because ICU is there for when I need
up-to-date unicode versions.
From my perspective, the whole point of the builtin collation was to
one option that avoids these problems that come with updating both ICU
and glibc.
So I
On Fri, Mar 21, 2025 at 8:13 PM Alvaro Herrera wrote:
>
> I passed PROVE_FLAGS="--timer -v" to get the timings and run under
> --format=directory.
>
> Without new test:
> ok23400 ms ( 0.00 usr 0.00 sys + 2.84 cusr 1.53 csys = 4.37 CPU)
> ok23409 ms ( 0.00 usr 0.01 sys + 2.81 cusr 1.
Robert Haas writes:
> On Sat, Oct 28, 2017 at 8:02 PM, Amit Kapila wrote:
>> I think we need to make changes in exec_simple_recheck_plan to make
>> the behavior similar to HEAD. With the attached patch, all tests
>> passed with force_parallel_mode.
> Committed to REL_10_STABLE.
Sorry for resur
On Wed, Mar 19, 2025 at 5:08 PM Peter Geoghegan wrote:
> The tricky logic added by 0003-* is my single biggest outstanding
> concern about the patch series. Particularly its potential to confuse
> the existing invariants for required arrays. And particularly in light
> of the changes that I made t
On Thu, Mar 20, 2025 at 9:02 PM Jacob Champion
wrote:
>
> On Thu, Mar 20, 2025 at 12:54 PM Matheus Alcantara
> wrote:
> > Since the security checks are defined I'm attaching 0003 which include
> > the fix of security checks for postgres_fdw. It implements the
> > validations very similar to what
Hi,
On 2025-03-19 09:17:23 +0200, Heikki Linnakangas wrote:
> On 19/03/2025 04:22, Tomas Vondra wrote:
> > I kept stress-testing this, and while the frequency massively increased
> > on PG18, I managed to reproduce this all the way back to PG14. I see
> > ~100x more corefiles on PG18.
> >
> > Tha
I passed PROVE_FLAGS="--timer -v" to get the timings and run under
--format=directory.
Without new test:
ok23400 ms ( 0.00 usr 0.00 sys + 2.84 cusr 1.53 csys = 4.37 CPU)
ok23409 ms ( 0.00 usr 0.01 sys + 2.81 cusr 1.53 csys = 4.35 CPU)
With new test, under --format=directory:
-j2
On Thu, Mar 20, 2025 at 3:41 PM vignesh C wrote:
>
> On Thu, 20 Mar 2025 at 10:25, Shubham Khanna
> wrote:
> >
> >
> > I have created two patches, v16-0001 and v16-0002, to address the
> > performance issue. I conducted performance testing, and here are the
> > results:
> > - The difference in ex
> In exec_bind_message(), the comment at the top of PortalDefineQuery()
> tells to not put any code between this call and the GetCachedPlan()
> that could issue an error. pgstat_report_plan_id() is OK, but I'd
> rather play it safe and set the ID once the portal is defined, based
> on portal->stmt
On Thu, 13 Mar 2025 at 18:10, Heikki Linnakangas wrote:
>
>
> Hmm, this problem isn't limited to this one pg_upgrade test, right? It
> could happen with any pg_upgrade invocation. And perhaps in a running
> server too, if a relfilenumber is reused quickly. In dropdb() and
> DropTableSpace() we do
I've just rebased patches and merged last two fix-commits (0003 and 0004)
into 0002.
--
regards
Yura Sokolov aka funny-falconFrom f8923c9b8e2f470dd3caaa1e71fb3b931389148b Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Fri, 21 Mar 2025 16:03:30 +0300
Subject: [PATCH v5 1/3] Reapply "libp
> > explain (query_tree_show range_table) select ..
> > explain (query_tree_show qualification) select ..
> > explain (query_tree_show target_list) select ..
>
> But why would those options be exclusive of each other? Surely you
> could want more than one of those things, which suggests that separa
On Thu, 20 Mar 2025 at 22:09, Alvaro Herrera wrote:
>
> On 2025-Mar-20, vignesh C wrote:
>
> > Will it help the execution time if we use --jobs in case of pg_dump
> > and pg_restore wherever supported:
>
> As I said in another thread, I think we should enable this test to run
> without requiring a
Hi,
Rebased it again.
On 2025-03-10 14:10, torikoshia wrote:
BTW the patch adds about 400 lines to explain.c and it may be better
to split the file as well as 9173e8b6046, but I leave it as it is for
now.
This part remains unchanged.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA G
On 2025-Mar-21, Ashutosh Bapat wrote:
> On Thu, Mar 20, 2025 at 8:37 PM vignesh C wrote:
> > Should the copyright be only 2025 in this case:
> The patch was posted in 2024 to this mailing list. So we better
> protect the copyright since then. I remember a hackers discussion
> where a senior mem
Hi,
On 2025-03-21 02:15, Fujii Masao wrote:
Thanks for your review!
Personally, I feel 1st patch may be sufficient, but I would appreciate
any feedback.
Agreed.
- errdetail("Consistent recovery state has not been yet
reached.")));
+
> On 21 Mar 2025, at 05:54, Melanie Plageman wrote:
>
> On Wed, Mar 19, 2025 at 5:26 AM Andrey Borodin wrote:
>>
>> So, yes, your change to the test seems correct to me. We can do the test
>> with just one injection point.
>
> Attached 0001 is what I plan to commit first thing tomorrow mor
On Thu, Mar 20, 2025 at 8:37 PM vignesh C wrote:
>
> Will it help the execution time if we use --jobs in case of pg_dump
> and pg_restore wherever supported:
> + $src_node->command_ok(
> + [
> + 'pg_dump', "-F$format", '--no-sync',
19.03.2025 19:05, Yura Sokolov wrote:
> 19.03.2025 05:09, David Rowley wrote:
>> On Tue, 18 Mar 2025 at 19:04, Stepan Neretin wrote:
>>> We propose modifying the truncation condition in should_attempt_truncation
>>> to avoid unnecessary full buffer scans.
>> I'm just following this code through.
Just rebased the patch.
---
regards
Yura Sokolov aka funny-falconFrom 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001
From: Yura Sokolov
Date: Mon, 3 Feb 2025 11:58:33 +0300
Subject: [PATCH v2] sinvaladt.c: use atomic operations on maxMsgNum
msgnumLock spinlock could be hig
Robert Haas writes:
> On Thu, Mar 20, 2025 at 3:47 PM David G. Johnston
> wrote:
>> While trying to find postgres.bki in my build directory searching for the
>> file name didn't work because there is no comment in the file containing the
>> file name; like there is in every other file we write
Hi,
On Wed, 12 Mar 2025 at 13:46, Rahila Syed wrote:
> I have now made the changes uniformly across shared and non-shared hash
> tables,
> making the code fix look cleaner. I hope this aligns with your suggestions.
> Please find attached updated and rebased versions of both patches.
Thank you f
You're right Dmitry, truncating the anonymous file before mapping it again
does the trick! I see 'HugePages_Free' increases to the expected size right
after the ftruncate call for shrinking.
This alternative approach looks very promising. Thanks.
Regards,
Jack Ng
On Fri, Mar 21, 2025 at 5:31 PM
On 3/19/25 13:27, Tomas Vondra wrote:
> On 3/19/25 08:17, Heikki Linnakangas wrote:
>> On 19/03/2025 04:22, Tomas Vondra wrote:
>>> I kept stress-testing this, and while the frequency massively increased
>>> on PG18, I managed to reproduce this all the way back to PG14. I see
>>> ~100x more corefil
On Fri, Mar 21, 2025 at 1:48 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Fri, Mar 21, 2025 at 12:50 PM Nisha Moond wrote:
>
> > Thanks, Hou-san, for the review and fix patches. I’ve incorporated
> > your suggestions.
> > Attached are the v7 patches, including patch 002, which implements
> > stats collec
On 18.03.25 21:18, Andres Freund wrote:
On 2025-03-13 09:37:37 +0100, Francesco Canovai wrote:
In this scenario, `tcp_user_timeout` could close a connection retrying
the SYNs (even though it doesn't seem to do it from the documentation,
it works) the parameter will affect the entire connection.
> On Fri, Mar 21, 2025 at 04:48:30PM GMT, Ni Ku wrote:
> Thanks for your insights and confirmation, Dmitry.
> Right, I think the anonymous fd approach would work to keep the memory
> contents intact in between munmap and mmap with the new size, so bufferpool
> expansion would work.
> But it seems s
On 21/3/2025 03:50, David Rowley wrote:
On Fri, 21 Mar 2025 at 07:54, Andrei Lepikhov wrote:
I have some doubts here.
The number of distinct values says something only when it has taken
together with the number of calls.
Couldn't the reader just look at the Nested Loop's outer side row
estima
68 matches
Mail list logo
