On Fri, May 09, 2025 at 07:21:17PM +0200, Daniel Gustafsson wrote:
> -=item $node->log_check($offset, $test_name, %parameters)
> +=item $node->log_check($test_name, $offset, %parameters)
>
> Check contents of server logs.
Right, good catch. The internals of the routine use %params instead
of %p
On Fri, May 9, 2025 at 1:51 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 2 May 2025 23:37:46 -0700,
> Masahiko Sawada wrote:
>
> > The progress information is stored in PgBackendStatus defined in
> > backend_stat
On Fri, May 09, 2025 at 03:59:48PM +, Greg Burd wrote:
> Apologies for that, somehow the wrong version of that file was
> attached. I'll be more careful next time.
No problem. This was mostly the same as the original. There was a
fuzz in 0001, actually, fixed by 0003 with the definitions of
On Sat, May 10, 2025 at 10:38:06AM +1200, David Rowley wrote:
> On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> > I will continue improving it until beta 1, and until the final release.
> > I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
>
> Minor detail, but "Improve t
I wrote:
> One thing I noticed while reading the Valgrind manual is that
> they describe a facility for "two level" tracking of custom
> allocators such as ours.
And, since there's nothing new under the sun around here,
we already had a discussion about that back in 2021:
https://www.postgresql.o
On Fri, May 9, 2025 at 2:41 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Sat, 3 May 2025 22:27:36 -0700,
> "David G. Johnston" wrote:
>
> > In any case, I’m doubtful either of us can make a convincing enough
> > argum
On 5/9/25 23:30, Matthias van de Meent wrote:
> ...
>> The difference shown by your flame graph is absolutely enormous --
>> that's *very* surprising to me. btbeginscan and btrescan go from being
>> microscopic to being very prominent. But skip scan simply didn't touch
>> either function, at all, d
Hi,
Chiming in as one of said providers...
> On Sat, 2025-04-05 at 19:07 -0400, Tom Lane wrote:
> > I took another look at this patch, and I still can't persuade
> > myself that a good case has been made for it. There are too
> > many scenarios where pg_manage_extensions would be a security
> > p
On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> I will continue improving it until beta 1, and until the final release.
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
Minor detail, but "Improve the performance and reduce memory usage of
hash joins and GROUP BY" proba
On Fri, 9 May 2025 at 20:38, Peter Geoghegan wrote:
>
> On Fri, May 9, 2025 at 2:04 PM Tomas Vondra wrote:
> > Yes, I'm sure it's doing index only scan
>
> Looks that way, from the pair of flame graphs you sent. Thanks for that.
>
> > did you update "bid" or did
> > you leave it as generated by "
Hi, Robert!
On 09.05.2025 20:12, Robert Haas wrote:
If I understand correctly, the problem here is that join removal and
minmax aggregates don't work well together: after join removal runs,
we end up with a state that doesn't permit the minmax-aggregate code
to work.
Yes, it is correct.
I agre
On Wed, Mar 5, 2025 at 2:30 PM Florents Tselai
wrote:
> I was thinking about taking another stab at this.
> Would someone more versed in the inner workings of jsonpath like to weigh in
> on the immutability wrt locale?
I'm not sure the issues with immutability here are particularly
related to js
On Fri, May 9, 2025 at 04:51:03PM +0800, Steven Niu wrote:
> Hi, Bruce,
>
> I have one comment, in E.1.3.4. Functions, crc32c also needs bracket.
> "Add functions crc32() and crc32c to compute CRC values" -->
> "Add functions crc32() and crc32c() to compute CRC values"
Thanks, fixed.
--
Bruc
On Fri, May 9, 2025 at 12:29 PM Tomas Vondra wrote:
> Tried, doesn't seem to affect the results at all.
OK, then. I don't think that we're going to figure it out this side of
pgConf.dev. I'm already well behind on talk preparation.
--
Peter Geoghegan
On Tue, May 06, 2025 at 03:39:07PM +, Gregory Burd wrote:
> 0001: Updates that comment so future authors know that this "stripped
> down function" should retain the logic in heap_page_prune_and_freeze(),
> not lazy_scan_prune() as was the case before 6dbb490.
Hm. It certainly had some resembl
Hi,
As I promised - meet parallel index autovacuum with bgworkers
(Parallel-index-autovacuum-with-bgworkers.patch). This is pretty
simple implementation :
1) Added new table option `parallel_idx_autovac_enabled` that must be
set to `true` if user wants autovacuum to process table in parallel.
2) Ad
On Thu, May 8, 2025 at 1:36 PM Paul A Jungwirth
wrote:
> v51 attached, just rebasing to b560ce7884.
I think these patches would benefit from some work to make them more
understandable for people who don't already know what they're intended
to accomplish. I suspect that's actually a prerequisite t
On Fri, May 9, 2025 at 2:04 PM Tomas Vondra wrote:
> Yes, I'm sure it's doing index only scan
Looks that way, from the pair of flame graphs you sent. Thanks for that.
> did you update "bid" or did
> you leave it as generated by "pgbench -i"?.
I didn't bother with updating, or running VACUUM FUL
On Fri, May 9, 2025 at 12:05:07PM +0900, Richard Guo wrote:
> > I think there are two patterns here:
> >
> > * 247dea89f and cc5d98525 fix cases where grouping expressions fail to
> > match lower-level target items due to expression preprocessing or
> > subquery pull-up. Subqueries are one exampl
> > To clarify, I had in mind something like in the attached patch. The
> > idea is to make start/end location capturing relatively independent from
> > the constants squashing. The new parsing node conveys the location
> > information, which is then getting transformed to be a part of an
> > Array
Andres Freund writes:
> On 2025-05-08 22:04:06 -0400, Tom Lane wrote:
>> A nearby thread [1] reminded me to wonder why we seem to have
>> so many false-positive leaks reported by Valgrind these days.
> Huh. We use the memory pool client requests to inform valgrind about memory
> contexts. I seem
On Fri, May 9, 2025 at 8:58 AM Tomas Vondra wrote:
> select count(*) from pgbench_accounts where bid = 0
What kind of plan are you getting? Are you sure it's index-only scans?
With 100 partitions, I get a parallel sequential scan when I run
EXPLAIN ANALYZE with this query from psql -- though o
On Fri, May 9, 2025 at 1:19 PM Tomas Vondra wrote:
> Not sure I understand. Why would it need to scan 85 index pages? There's
> only 100 matching tuples total, spread over the 100 partitions. We'll
> need to scan maybe 1 page per partition.
I was unclear. The thing about 85 leaf pages only applie
On Tue, May 6, 2025 at 11:08 PM Gregory Burd wrote:
> While working on [1] I found an outdated comment in
> heap_page_is_all_visible() and two other small fixes.
>
> 0001: Updates that comment so future authors know that this "stripped down
> function" should retain the logic in heap_page_prune_a
While writing tests today I noticed that the order of the parameters in the POD
docs for log_check() in PostgreSQL::Test::Cluster is wrong, the first parameter
is the test name. Will apply the below later today with a backpatch to where
26eaf82e7138 went in.
diff --git a/src/test/perl/PostgreSQL/
On 5/9/25 18:36, Peter Geoghegan wrote:
> On Fri, May 9, 2025 at 12:28 PM Tomas Vondra wrote:
>> Not sure if it matters, but this uses index-only scans, and the pages
>> are all-visible, so maybe it's not much more expensive.
>
> You're still going to have to scan 85 full index pages on your
> pg
Hi Alena,
If I understand correctly, the problem here is that join removal and
minmax aggregates don't work well together: after join removal runs,
we end up with a state that doesn't permit the minmax-aggregate code
to work.
I agree that would be good to fix but the patch doesn't seem right to m
Hi Tomas,
> While running some benchmarks comparing 17 and 18, I ran into a simple
> workload where 18 throughput drops by ~80%. After pulling my hair for a
> couple hours I realized the change that triggered this is 04bec894a04c,
> which set checksums on by default. Which is very bizarre, because
> On 9 May 2025, at 18:42, Tom Lane wrote:
>
> Pushed all that stuff. The SSL tests pass for me now on OpenBSD 7.7,
> and hopefully the CI environment will be happy too.
Thanks!
--
Daniel Gustafsson
Hi!
On 22.04.2025 21:23, Andrei Lepikhov wrote:
On 10/28/24 14:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
If I missed something or misunderstood, can you explain in more detail?
Actually, I mean why do we need a possibility to return statistics for
all table
Pushed all that stuff. The SSL tests pass for me now on OpenBSD 7.7,
and hopefully the CI environment will be happy too.
regards, tom lane
On Fri, May 9, 2025 at 12:28 PM Tomas Vondra wrote:
> Not sure if it matters, but this uses index-only scans, and the pages
> are all-visible, so maybe it's not much more expensive.
You're still going to have to scan 85 full index pages on your
pgbench_accounts.bid index -- that's pretty expensiv
Andres Freund writes:
> Briefly looking through the leaks indeed quickly found a real seeming leak,
> albeit of limited size:
> ProcessStartupPacket() does
> buf = palloc(len + 1);
> in TopMemoryContext() without ever freeing it.
Yeah, I saw that too. Didn't seem worth doing anything about
On Wed, May 7, 2025 at 02:52:27PM -0700, Jacob Champion wrote:
> On Wed, May 7, 2025 at 2:45 PM Jonathan S. Katz wrote:
> > I did a double take on the current sentence, and revised it to:
> >
> > ==
> > PostgreSQL 18 introduces `oauth` authentication, which lets users
> > authenticate using OAuth
On 5/9/25 18:09, Peter Geoghegan wrote:
> On Fri, May 9, 2025 at 11:55 AM Peter Geoghegan wrote:
>> Note that "sizeof(FmgrInfo)" is 48 bytes. Prior to skip scan,
>> RelationData.rd_supportinfo would have required 48*5=240 bytes. After
>> skip scan, it would have required 48*6=288 bytes. Maybe 256
On 5/9/25 17:55, Peter Geoghegan wrote:
> On Fri, May 9, 2025 at 10:57 AM Tomas Vondra wrote:
>> I see the regression even with variants that actually match some rows.
>> For example if I do this:
>
>> so that the query matches 100 rows, I get the same behavior.
>
> That's really weird, since th
On Fri, May 9, 2025 at 11:55 AM Peter Geoghegan wrote:
> Note that "sizeof(FmgrInfo)" is 48 bytes. Prior to skip scan,
> RelationData.rd_supportinfo would have required 48*5=240 bytes. After
> skip scan, it would have required 48*6=288 bytes. Maybe 256 bytes is
> some kind of critical threshold, s
Hi, Bruce,
I have one comment, in E.1.3.4. Functions, crc32c also needs bracket.
"Add functions crc32() and crc32c to compute CRC values" -->
"Add functions crc32() and crc32c() to compute CRC values"
Regards,
Steven
在 2025/5/2 10:44, Bruce Momjian 写道:
> I have committd the first draft of the P
On Fri, May 9, 2025 at 10:57 AM Tomas Vondra wrote:
> I see the regression even with variants that actually match some rows.
> For example if I do this:
> so that the query matches 100 rows, I get the same behavior.
That's really weird, since the index scans will no longer be cheap.
And yet what
Hi,
On 2025-05-09 11:29:43 -0400, Andres Freund wrote:
> We currently don't reset TopMemoryContext at exit, which, obviously, does
> massively increase the number of leaks. But OTOH, without that there's not a
> whole lot of value in the leak check...
Briefly looking through the leaks indeed quic
Hi Stepan,
> Sorry for the noise — I'm resending the patch because I noticed a compiler
> warning related to mixed declarations and code, which I’ve now fixed.
>
> Apologies for the oversight in the previous submission.
Thanks for the patch.
As Kirill pointed out above, it would be nice if you
Hi,
On 2025-05-08 22:04:06 -0400, Tom Lane wrote:
> A nearby thread [1] reminded me to wonder why we seem to have
> so many false-positive leaks reported by Valgrind these days.
> For example, at exit of a backend that's executed a couple of
> trivial queries, I see
>
> ==00:00:00:25.515 260013==
On 5/9/25 16:22, Peter Geoghegan wrote:
> On Fri, May 9, 2025 at 9:59 AM Peter Geoghegan wrote:
>> I don't actually think that this kind of scan would have been affected
>> by those known regressions -- since they don't use array keys. But it
>> is definitely true that the queries that you're look
On Mon, 28 Apr 2025 at 19:57, Álvaro Herrera wrote:
>
> On 2025-Apr-28, Shlok Kyal wrote:
>
> > 2.
> > + * We also take a ShareLock on pg_partitioned_table to restrict addition
> > + * of new partitioned table which may contain a foreign partition while
> > + * publication is being created. XXX
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 May 2025 23:37:46 -0700,
Masahiko Sawada wrote:
> The progress information is stored in PgBackendStatus defined in
> backend_status.h:
>
> /*
> * Command progress reporting. Any command wh
On 5/9/25 16:17, Peter Geoghegan wrote:
> On Fri, May 9, 2025 at 8:58 AM Tomas Vondra wrote:
>> I'm also not sure about the root cause, but while investigating it one
>> of the experiments I tried was tweaking the glibc malloc by setting
>>
>> export MALLOC_TOP_PAD_=$((64*1024*1024))
>>
>>
On Wed, May 7, 2025 at 11:04 AM Jack Ng wrote:
> > all the possible scenarios. But now I'm reworking it along the lines
> suggested
> > by Thomas, and will address those as well. Thanks!
>
> Thanks for the info, Dmitry.
> Just want to confirm my understanding of Thomas' suggestion and your
> disc
Daniel Gustafsson writes:
> On 9 May 2025, at 02:15, Tom Lane wrote:
>> Right. I think the attached would be amenable to that.
> It will be a bit awkward to ask "are you libressl" if we ever add support for
> something not OpenSSL based, but we could always revisit should that happen.
I was im
On Fri, May 9, 2025 at 7:43 PM Aleksander Alekseev
wrote:
> Hi Stepan,
>
> > Sorry for the noise — I'm resending the patch because I noticed a
> compiler warning related to mixed declarations and code, which I’ve now
> fixed.
> >
> > Apologies for the oversight in the previous submission.
>
> Tha
On Fri, May 9, 2025 at 9:59 AM Peter Geoghegan wrote:
> I don't actually think that this kind of scan would have been affected
> by those known regressions -- since they don't use array keys. But it
> is definitely true that the queries that you're looking at very much
> rely on the optimization f
On 5/9/25 14:43, Arseniy Mukhin wrote:
> Hello,
>
> Thanks everybody for the patch.
>
> I noticed there are no tests that GIN check fails if the index is
> corrupted, so I thought it would be great to have some.
> While writing tests I noticed some issues in the patch (all issues are
> for verify
On Fri, May 9, 2025 at 8:58 AM Tomas Vondra wrote:
> I'm also not sure about the root cause, but while investigating it one
> of the experiments I tried was tweaking the glibc malloc by setting
>
> export MALLOC_TOP_PAD_=$((64*1024*1024))
>
> which keeps a 64MB "buffer" in glibc, to reduce the
On 5/9/25 15:59, Peter Geoghegan wrote:
> On Fri, May 9, 2025 at 9:42 AM Peter Geoghegan wrote:
>> I'm rather puzzled as to why this happens, then. I expect that nbtree
>> preprocessing will be able to use its usual single index column/index
>> key fast path here -- the "We can short-circuit most
On Fri, May 9, 2025 at 9:33 AM Peter Geoghegan wrote:
> Can you try it again, with prepared statements? Alternatively, you
> could selectively revert the changes that commit 92fe23d93aa made to
> utils/adt/selfuncs.c, and then retest.
Oh, wait, you already did try it with prepared statements.
I'
On Fri, May 9, 2025 at 9:42 AM Peter Geoghegan wrote:
> I'm rather puzzled as to why this happens, then. I expect that nbtree
> preprocessing will be able to use its usual single index column/index
> key fast path here -- the "We can short-circuit most of the work if
> there's just one key" path i
On Fri, May 9, 2025 at 8:58 AM Tomas Vondra wrote:
> My conclusion from this is that 92fe23d93aa ends up doing a lot of
> malloc calls, and this is what makes causes the regression. Otherwise
> setting the MALLOC_TOP_PAD_ would not help like this. But I haven't
> looked at the code, and I wouldn't
Hi,
> > I'm not claiming that hint bits are necessarily the reason for the
> > observed behavior but when something is off with presumably read-only
> > queries this is the first reason that comes to mind. At least we
> > should make sure hint bits are excluded from the equation. If memory
> > ser
On 5/9/25 14:53, Aleksander Alekseev wrote:
> Hi Tomas,
>
>> While running some benchmarks comparing 17 and 18, I ran into a simple
>> workload where 18 throughput drops by ~80%. After pulling my hair for a
>> couple hours I realized the change that triggered this is 04bec894a04c,
>> which set che
Hi,
While doing some benchmarks to compare 17 vs. 18, I ran into a
regression that I ultimately tracked to commit 92fe23d93aa.
commit 92fe23d93aa3bbbc40fca669cabc4a4d7975e327
Author: Peter Geoghegan
Date: Fri Apr 4 12:27:04 2025 -0400
Add nbtree skip scan optimization.
The wo
Hello,
Thanks everybody for the patch.
I noticed there are no tests that GIN check fails if the index is
corrupted, so I thought it would be great to have some.
While writing tests I noticed some issues in the patch (all issues are
for verify_gin.c)
1) When we add new items to the entry tree sta
On Fri, May 9, 2025 at 5:24 PM Stepan Neretin wrote:
>
>
> On Wed, Mar 26, 2025 at 9:39 PM Steven Niu wrote:
>
>>
>> 在 2025/3/26 16:37, Kirill Reshke 写道:
>> > On Wed, 26 Mar 2025 at 12:17, Steven Niu wrote:
>> >>
>> >> Hi,
>> >
>> > Hi!
>> >
>> >> This double scanning can be inefficient, especi
On Thu, May 8, 2025 at 11:35 AM shveta malik wrote:
>
> On Wed, May 7, 2025 at 4:36 PM Nisha Moond wrote:
> >
> >
> > Attached is the v13 patch with the above comments addressed.
> >
> > --
>
> Thanks for the patch.
>
> I think we can have the restriction mentioned under the 'two_phase'
> section
Hi,
While running some benchmarks comparing 17 and 18, I ran into a simple
workload where 18 throughput drops by ~80%. After pulling my hair for a
couple hours I realized the change that triggered this is 04bec894a04c,
which set checksums on by default. Which is very bizarre, because the
workload
On Fri, May 9, 2025 at 5:37 PM Stepan Neretin wrote:
>
>
> On Fri, May 9, 2025 at 5:24 PM Stepan Neretin wrote:
>
>>
>>
>> On Wed, Mar 26, 2025 at 9:39 PM Steven Niu wrote:
>>
>>>
>>> 在 2025/3/26 16:37, Kirill Reshke 写道:
>>> > On Wed, 26 Mar 2025 at 12:17, Steven Niu wrote:
>>> >>
>>> >> Hi,
>
On Fri, May 9, 2025 at 7:04 AM Tom Lane wrote:
> A nearby thread [1] reminded me to wonder why we seem to have
> so many false-positive leaks reported by Valgrind these days.
> For example, at exit of a backend that's executed a couple of
> trivial queries, I see
>
> ==00:00:00:25.515 260013== LE
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 3 May 2025 22:27:36 -0700,
"David G. Johnston" wrote:
> In any case, I’m doubtful either of us can make a convincing enough
> argument to sway the other fully. Both options are plausible, IMO. Others
On Wed, Mar 26, 2025 at 9:39 PM Steven Niu wrote:
>
> 在 2025/3/26 16:37, Kirill Reshke 写道:
> > On Wed, 26 Mar 2025 at 12:17, Steven Niu wrote:
> >>
> >> Hi,
> >
> > Hi!
> >
> >> This double scanning can be inefficient, especially for large inputs.
> >> So I optimized the function to eliminate th
On 2025-Apr-14, Richard Guo wrote:
> It seems what happens is that internally in gram.y (~line 14274), the
> DefElem for the not-null option is assigned the name "is_not_null".
> As a result, this allows users to explicitly use "is_not_null" as the
> option name. However, the value provided for t
On Sat, May 3, 2025 at 7:27 PM vignesh C wrote:
>
> >
> > Thanks for the comments, the updated patch has the changes for the same.
>
Thanks for the patches. Please find few comments:
1)
patch004 commit msg:
- Drop published sequences are removed from pg_subscription_rel.
Drop -->Dropped
2)
c
> On Fri, May 09, 2025 at 08:47:58AM GMT, Michael Paquier wrote:
> SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
> - query| calls
> -+---
> - SELECT ARRAY[$1 /*, ... */]
> On Fri, May 09, 2025 at 02:35:33PM GMT, Michael Paquier wrote:
> On Fri, May 09, 2025 at 11:05:43AM +0800, Junwang Zhao wrote:
> > Why not a location and a length, it should be more natural, it
> > seems we use this convention in some existing nodes, like
> > RawStmt, InsertStmt etc.
>
> These ar
> On 9 May 2025, at 02:15, Tom Lane wrote:
> Daniel Gustafsson writes:
>> If we were to end up with a
>> Libressl libtls implementation in libpq we'd still have to test with Libressl
>> against the OpenSSL compat layer in libssl since it could act as both. Not a
>> bridge we have to cross today
72 matches
Mail list logo
