> Hmm, that seems like their problem not ours. It's not very clear
> to me why they'd want to force these flags from the compiler
> command line in the first place, but if they do they should be
> consistent with the more usual ways to set them.
There is no particular need to merge this patch for
21.08.2024 13:00, Alexander Lakhin wrote:
As a recent failure, produced by drongo [1], shows, pg_ctl stop/start
sequence may break on Windows due to the transient DELETE PENDING state of
posmaster.pid.
lorikeet didn't lose it's chance to add two cents to the conversation and
failed on "pg_ctl
On Thu, Aug 22, 2024 at 7:31 PM Mats Kindahl wrote:
> The alternate version proposed by Nazir allows you to decide which interface
> to use.
> Reverting the patch entirely would also solve the problem.
> Passing down the block sampler and the strategy to scan_begin() and move the
> ReadStream se
Hi Ashutosh, thank you for your response.
Firstly, the purpose of caching memory in malloc is for performance, so
when we execute malloc_trim(), it will affect the efficiency of memory
usage in the subsequent operation. Secondly, the function of malloc_trim()
is to lock and traverse the bins, then
Thank you Rafia. Here is a v2 patch.
Rafia Sabih 于2024年8月23日周五 18:30写道：
>
>
> On Fri, 23 Aug 2024 at 10:54, shawn wang wrote:
>
>> Hi hackers,
>>
>> Currently, all processes in PostgreSQL actually use malloc to allocate
>> and free memory. In the case of long connections where business queries
On Fri, Aug 23, 2024 at 9:02 PM Peter Eisentraut wrote:
>
> On 15.08.24 12:25, Junwang Zhao wrote:
> > I noticed that there is a magic number which can be replaced by
> > CATCACHE_MAXKEYS
> > in struct cachedesc, I checked some other struct like CatCache, CatCTup,
> > they
> > all use CATCACHE_M
On Sat, Aug 24, 2024, at 00:00, Joel Jacobson wrote:
> Since statistical tools that rely on normal distributions can't be used,
> let's look at the individual measurements for (var1ndigits=3, var2ndigits=3)
> since that seems to be the biggest slowdown on both CPUs,
> and see if our level of surpri
Alvaro Herrera writes:
> On 2024-Aug-23, Michael Paquier wrote:
>>> I've been curious about what exactly does this Makefile line
>>> export enable_injection_points enable_injection_points
>>> achieve.
>> Without this line, the TAP tests would not be able to know if
>> injection points are enabled
On Sat, Aug 24, 2024 at 10:33 AM Nathan Bossart
wrote:
> I am seeing the exact problem described in this thread on my laptop since
> commit 490f869. I have yet to do a thorough investigation, but what I've
> seen thus far does seem to fit the subtle-differences-in-generated-WAL
> theory. If no o
I am seeing the exact problem described in this thread on my laptop since
commit 490f869. I have yet to do a thorough investigation, but what I've
seen thus far does seem to fit the subtle-differences-in-generated-WAL
theory. If no one is planning to pick up the fix soon, I will try to.
--
nath
On 2024-Aug-23, Michael Paquier wrote:
> On Tue, Aug 20, 2024 at 12:30:35PM -0400, Alvaro Herrera wrote:
> > Yeah, I like this option. Injection points require to be explicitly
> > enabled in configure, so skipping that test when injection_points can't
> > be found seems reasonable.
>
> My apolo
Hmm… so you're worried about people setting the definition to 0 for
disabled and nonzero || present for enabled? - I suppose all the
`#define`s in PostgreSQL could be guarded and checked for both
presence and either empty value or value. But maybe you just don't
want to touch this side of the codeb
On Fri, Aug 23, 2024, at 21:21, Joel Jacobson wrote:
> Attachments:
> * perf_test-M3 Max.out
> * perf_test-Intel Core i9-14900K.out
> * perf_test-AMD Ryzen 9 7950X3D.out
Here are some additional benchmarks from pg-catbench:
AMD Ryzen 9 7950X3D:
select x var1ndigits,y
var2ndigits,a_avg,b_avg,poo
On 8/23/24 5:33 PM, Jonathan S. Katz wrote:
On 8/23/24 3:32 PM, Tom Lane wrote:
Robert Haas writes:
I think it's not that bad, because we can limit the knowledge of this
hack to the amcostestimate interface, which doesn't really deal in
"the user told us not to do it this way" at all. That
Samuel Marks writes:
> It will resolve the large number of these warnings from
> https://github.com/pgcentralfoundation/pgrx/blob/6dfb9d1/cargo-pgrx/src/command/init.rs#L411-L412:
Hmm, that seems like their problem not ours. It's not very clear
to me why they'd want to force these flags from the
On 8/23/24 3:32 PM, Tom Lane wrote:
Robert Haas writes:
I find both of your proposed solutions above to be pretty inelegant,
They are that. If we were working in a green field I'd not propose
such things ... but we aren't. I believe there are now a fair number
of out-of-core index AMs, so I
On 8/23/24 2:29 PM, Robert Haas wrote:
On Fri, Aug 23, 2024 at 2:20 PM Jonathan S. Katz wrote:
I don't think extension maintainers necessarily have the same level of
PostgreSQL internals as you or many of the other people who frequent
-hackers, so I think it's fair for them to ask questions or
It will resolve the large number of these warnings from
https://github.com/pgcentralfoundation/pgrx/blob/6dfb9d1/cargo-pgrx/src/command/init.rs#L411-L412:
: note: this is the location of the previous definition
./../../src/include/pg_config_manual.h:274: warning:
"MEMORY_CONTEXT_CHECKING" redefine
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi
the patch looks good to me as well. Calling smgrclose() right after calli
Samuel Marks writes:
> Subject: [PATCH] [src/include/pg_config_manual.h] Guard `CLOBBER_FREED_MEMORY`
> & `MEMORY_CONTEXT_CHECKING`
Why is this a good idea?
regards, tom lane
>From 73dbe66c0ed68ae588223639a2ba93f6a727b704 Mon Sep 17 00:00:00 2001
From: Samuel Marks <807580+samuelma...@users.noreply.github.com>
Date: Fri, 23 Aug 2024 16:03:41 -0500
Subject: [PATCH] [src/include/pg_config_manual.h] Guard `CLOBBER_FREED_MEMORY`
& `MEMORY_CONTEXT_CHECKING`
---
src/includ
On Fri, Aug 23, 2024, at 21:21, Joel Jacobson wrote:
> On Fri, Aug 23, 2024, at 15:49, Dean Rasheed wrote:
>> The attached patch attempts to resolve those issues by replacing
>> div_var() and div_var_fast() with a single function intended to be
>> faster than both the originals.
...
> I've had an i
On Wed, Aug 21, 2024 at 7:08 AM Amul Sul wrote:
> I have reworked a few comments, revised error messages, and made some
> minor tweaks in the attached version.
Thanks.
> Additionally, I would like to discuss a couple of concerns regarding
> error placement and function names to gather your sugge
On Fri, Aug 23, 2024 at 7:42 AM Jelte Fennema-Nio wrote:
>
> On Fri, 23 Aug 2024 at 16:02, Robert Haas wrote:
> > Personally, I'm 100% convinced at this point that we're arguing about
> > the wrong problem. Before, I didn't know for sure whether anyone would
> > be mad if we redefined PQprotocolV
Robert Haas writes:
> I find both of your proposed solutions above to be pretty inelegant,
They are that. If we were working in a green field I'd not propose
such things ... but we aren't. I believe there are now a fair number
of out-of-core index AMs, so I'd rather not break all of them if we
On 23/08/2024 22:05, Robert Haas wrote:
On Fri, Aug 23, 2024 at 2:48 PM Tom Lane wrote:
If we're going to do this, I'd prefer a solution that doesn't force
API changes onto the vast majority of index AMs that don't have a
problem here.
That's a fair concern.
Yeah, although I don't think it'
On Fri, Aug 23, 2024 at 2:48 PM Tom Lane wrote:
> If we're going to do this, I'd prefer a solution that doesn't force
> API changes onto the vast majority of index AMs that don't have a
> problem here.
That's a fair concern.
> One way could be to formalize the hack we were just discussing:
> "To
On Fri, Aug 23, 2024 at 02:20:06PM +0300, Nazir Bilal Yavuz wrote:
> On Tue, 20 Aug 2024 at 21:47, Noah Misch wrote:
> > On Tue, Aug 13, 2024 at 03:22:27PM +0300, Nazir Bilal Yavuz wrote:
> > > The downside of this approach is there are too many "vmbuffer is valid
> > > but BufferGetBlockNumber(*v
Robert Haas writes:
> On Fri, Aug 23, 2024 at 2:18 PM Heikki Linnakangas wrote:
>> It would seem useful for an index AM to be able to say "nope, I can't do
>> this". I don't remember how exactly this stuff works, but I'm surprised
>> it doesn't already exist.
> Yeah, I think so, too. While this
On Fri, Aug 23, 2024 at 2:18 PM Heikki Linnakangas wrote:
> It would seem useful for an index AM to be able to say "nope, I can't do
> this". I don't remember how exactly this stuff works, but I'm surprised
> it doesn't already exist.
Yeah, I think so, too. While this particular problem is due to
On Fri, Aug 23, 2024 at 2:20 PM Jonathan S. Katz wrote:
> I don't think extension maintainers necessarily have the same level of
> PostgreSQL internals as you or many of the other people who frequent
> -hackers, so I think it's fair for them to ask questions or raise issues
> with patches they don
On 8/23/24 1:11 PM, Robert Haas wrote:
On Fri, Aug 23, 2024 at 11:17 AM Jonathan S. Katz wrote:
We hit an issue with pgvector[0] where a regular `SELECT count(*) FROM
table`[1] is attempting to scan the index on the vector column when
`enable_seqscan` is disabled. Credit to Andrew Kane (CC'd) f
On 23/08/2024 20:11, Robert Haas wrote:
I find it a little weird that hnsw thinks itself able to return all
the tuples in an order the user chooses, but unable to return all of
the tuples in an arbitrary order.
HNSW is weird in many ways:
- There is no inherent sort order. It cannot do "ORDER
Robert Haas writes:
> On Fri, Aug 23, 2024 at 1:26 PM Tom Lane wrote:
>> It looks like amcostestimate could change the path's disabled_nodes
>> count, since that's set up before invoking amcostestimate. I guess
>> it could be set to INT_MAX to have a comparable solution to before.
> It's probab
On Fri, Aug 23, 2024 at 1:26 PM Tom Lane wrote:
> It looks like amcostestimate could change the path's disabled_nodes
> count, since that's set up before invoking amcostestimate. I guess
> it could be set to INT_MAX to have a comparable solution to before.
It's probably better to add a more mode
Robert Haas writes:
> On Fri, Aug 23, 2024 at 11:17 AM Jonathan S. Katz
> wrote:
>> We hit an issue with pgvector[0] where a regular `SELECT count(*) FROM
>> table`[1] is attempting to scan the index on the vector column when
>> `enable_seqscan` is disabled. Credit to Andrew Kane (CC'd) for flag
On Fri, Aug 23, 2024 at 11:17 AM Jonathan S. Katz wrote:
> We hit an issue with pgvector[0] where a regular `SELECT count(*) FROM
> table`[1] is attempting to scan the index on the vector column when
> `enable_seqscan` is disabled. Credit to Andrew Kane (CC'd) for flagging it.
>
> I was able to tr
Hi, Alena!
On Fri, Aug 23, 2024 at 5:06 PM Alena Rybakina
wrote:
> To be fair, I fixed this before [0] by selecting the appropriate group
> of "or" expressions to transform them to "ANY" expression and then
> checking for compatibility with the index column. maybe we should try
> this too? I can
On Fri, Aug 23, 2024 at 5:59 AM Ashutosh Bapat
wrote:
> If I run
> export PG_TEST_EXTRA=xid_wraparound; ./configure --prefix=$BuildDir
> --enable-tap-tests && make -j4 && make -j4 install; unset
> PG_TEST_EXTRA
> followed by
> make -C $XID_MODULE_DIR check where
> XID_MODULE_DIR=src/test/modules/x
On Wed, Aug 21, 2024 at 3:11 AM Richard Guo wrote:
> Attached is the updated version of the patchset that fixes this bug
> and includes further code refactoring.
Here are some initial, high-level thoughts about this patch set.
1. As far as I can see, there's no real performance testing on this
t
On 8/21/24 10:29 AM, Robert Haas wrote:
I went ahead and committed these patches. I know there's some debate
over whether we want to show the # of disabled nodes and if so whether
it should be controlled by COSTS, and I suspect I haven't completely
allayed David's concerns about the initial_cost
On Thu, Aug 15, 2024 at 5:02 PM Nathan Bossart wrote:
> On Wed, Aug 07, 2024 at 02:01:30PM -0400, Robert Haas wrote:
> > Also, for the notes to be useful, we'd probably need some conventions
> > about how we, as a project, want to use them. If everyone does
> > something different, the result isn'
On Fri, 23 Aug 2024 at 16:02, Robert Haas wrote:
> Personally, I'm 100% convinced at this point that we're arguing about
> the wrong problem. Before, I didn't know for sure whether anyone would
> be mad if we redefined PQprotocolVersion(), but now I know that there
> is at least one person who wil
On Fri, Aug 23, 2024 at 03:17:17PM +0200, Peter Eisentraut wrote:
> On 08.08.24 19:19, Greg Sabino Mullane wrote:
> > Thank you for the feedback. Please find attached three separate patches.
> > One to add a new flag to initdb (--no-data-checksums), one to adjust the
> > tests to use this flag as n
Hi,
The date for PostgreSQL 17 Release Candidate 1 (RC1) is September 5,
2024. Please ensure all open items[1] are completed and committed before
August 31, 2024 12:00 UTC to allow enough time for them to clear the
buildfarm.
The current target date for the PostgreSQL 17 GA release is Septem
Hi!
To be fair, I fixed this before [0] by selecting the appropriate group
of "or" expressions to transform them to "ANY" expression and then
checking for compatibility with the index column. maybe we should try
this too? I can think about it.
[0]
https://www.postgresql.org/message-id/531fc
On Wed, Aug 21, 2024 at 3:14 PM Jacob Champion
wrote:
> Put another way: we've seen that our protocol-version joint has rusted
> [1, 2]. I agree that needs to be fixed. But I also believe that we
> shouldn't try to smash the joint open with a hammer, and that belief
> seems philosophically at odds
Rebased and reworked patches attached:
v2-0001-Add-new-initdb-argument-no-data-checksums-to-force-checksums-off.patch
- Adds --no-data-checksums to initdb.c, adjusts --help and sgml docs, adds
simple tests
v2-0002-Allow-tests-to-force-checksums-off-when-calling-init.patch
- Adjusts the Perl tests
On 08.08.24 19:19, Greg Sabino Mullane wrote:
Thank you for the feedback. Please find attached three separate patches.
One to add a new flag to initdb (--no-data-checksums), one to adjust the
tests to use this flag as needed, and the final to make the actual
switch of the default value (along w
On 15.08.24 12:25, Junwang Zhao wrote:
I noticed that there is a magic number which can be replaced by CATCACHE_MAXKEYS
in struct cachedesc, I checked some other struct like CatCache, CatCTup, they
all use CATCACHE_MAXKEYS.
The "syscache" is the only user of the "catcache" right now. But I
th
Hi!
Thank you for your feedback.
On Fri, Aug 23, 2024 at 1:23 PM Andrei Lepikhov wrote:
>
> On 21/8/2024 16:52, Alexander Korotkov wrote:
> >> /* Only operator clauses scan match */
> >> Should it be:
> >> /* Only operator clauses can match */
> >> ?
> >
> > Corrected, thanks.
> I found one more
Hi Jacob,
On Wed, Aug 14, 2024 at 6:19 PM Jacob Champion
wrote:
>
> On Tue, Aug 13, 2024 at 9:07 PM Ashutosh Bapat
> wrote:
> > > I'm not entirely sure what you mean? src/test should work fine,
> > > anything lower than that (say src/test/ssl) does not.
> >
> > I could run them from src/test/mod
On 8/23/24 14:00, Peter Eisentraut wrote:
> On 30.06.24 20:58, Tomas Vondra wrote:
>> I've pushed the first three patches, fixing the headers, adding the
>> --copy option and PG_TEST_PG_COMBINEBACKUP_MODE variable.
>>
>> I haven't pushed the CI changes, I'm not sure if there's a clear
>> consensu
On Wed, Aug 21, 2024 at 10:10 PM Robert Haas wrote:
> On Wed, Aug 21, 2024 at 8:45 AM Amit Langote wrote:
> > * The replanning aspect of the lock-in-the-executor design would be
> > simpler if a CachedPlan contained the plan for a single query rather
> > than a list of queries, as previously ment
On 01.07.24 12:33, Dean Rasheed wrote:
Attached is a patch adding support for the gamma and log-gamma
functions. See, for example:
https://en.wikipedia.org/wiki/Gamma_function
I think these are very useful general-purpose mathematical functions.
They're part of C99, and they're commonly include
So, for our production use, we want to achieve $subj. The problem is
not new [1], as well as solutions to it[2]. So, what is the problem?
On one hand, we cannot resolve this issue with some primitive log
chunk truncation mechanism inside core (the way it is done in
greenplum db for example[3]), be
Hi Rafia.
Em qui., 22 de ago. de 2024 às 17:17, Rafia Sabih
escreveu:
>
>
> On Thu, 22 Aug 2024 at 15:02, Ranier Vilela wrote:
>
>> Hi.
>>
>> Em qui., 22 de ago. de 2024 às 04:34, Richard Guo
>> escreveu:
>>
>>> I ran into a query plan where the Result node seems redundant to me:
>>>
>>> creat
On 18.08.24 15:35, Peter Eisentraut wrote:
On 17.08.24 00:01, Thomas Munro wrote:
Hmm. fd.h and fd.c test for F_NOCACHE, which is pretty closely
related. Now I'm wondering why we actually need this in
pg_config_manual.h at all. Who would turn it off at compile time, and
why would they not be
On Thu, Aug 22, 2024 at 12:33 PM Thomas Munro wrote:
> I fear that back-porting, for the LLVM project, would mean "we fix it
> in main/20.x, and also back-port it to 19.x". Do distros back-port
> further?
That's also my fear, I'm not familiar with distros back-port policy
but eyeballing ubuntu p
On Fri, Aug 23, 2024 at 7:02 AM bucoo wrote:
> Howerver, the non-parallel hashjoin indeed showed about a 10% performance
> improvement.
>-> Hash Join (cost=508496.00..2302429.31 rows=47989008 width=0) (actual
> time=1075.213..9503.727 rows=47989007 loops=1)
>-> Hash Join (cost=508496
On 23/08/2024 14:50, Jingtang Zhang wrote:
Hi hackers. I found a strange point when I was reading the heapam
handlers of table access method, where heapam_tuple_insert and several
handlers explicitly assign t_tableOid of the tuple to be operated,
while later the t_tableOid is assigned again by li
Hi Shawn,
On Fri, Aug 23, 2024 at 2:24 PM shawn wang wrote:
>
> Hi hackers,
>
> Currently, all processes in PostgreSQL actually use malloc to allocate and
> free memory. In the case of long connections where business queries are
> executed over extended periods, the distribution of memory can
On 30.06.24 20:58, Tomas Vondra wrote:
I've pushed the first three patches, fixing the headers, adding the
--copy option and PG_TEST_PG_COMBINEBACKUP_MODE variable.
I haven't pushed the CI changes, I'm not sure if there's a clear
consensus on which combination to test. It's something we can twea
Hi hackers. I found a strange point when I was reading the heapam
handlers of table access method, where heapam_tuple_insert and several
handlers explicitly assign t_tableOid of the tuple to be operated,
while later the t_tableOid is assigned again by like heap_prepare_insert or
so. Is it redundant
Hi,
Thanks for the review and feedback!
On Tue, 20 Aug 2024 at 21:47, Noah Misch wrote:
>
> On Tue, Aug 13, 2024 at 03:22:27PM +0300, Nazir Bilal Yavuz wrote:
> > 2- collect_corrupt_items()
> >
> > This one is more complicated. The read stream callback function loops
> > until it finds a suitabl
On 8/23/24 12:02 PM, Rafia Sabih wrote:> On the other hand, this got me
thinking about the purpose of this space > information.
If we want to understand that there's still some space for the tuples in
a page, then using PageGetExactFreeSpace is not doing justice in case of
heap page, because we
> * mtup is hold in hjstate->hj_outerTupleBuffer, so we can using
> * shouldFree as false to call ExecForceStoreMinimalTuple().
> *
> * When slot is TTSOpsMinimalTuple we can avoid realloc memory for
> * new MinimalTuple(reuse StringInfo to call ExecHashJoinGetSavedTuple).
>
> But my point
Hi Shubham,
I have reviewed v28* and posted updated v29 versions of patches 0001 and 0002.
If you are OK with these changes, the next task would be to pg_indent
them, then rebase the remaining patches (0003 etc.) and include those
with the next patchset version.
//
Patch v29-0001 change
On 8/23/24 12:02, Rafia Sabih wrote:
On the other hand, this got me thinking about the purpose of this space
information.
If we want to understand that there's still some space for the tuples in
a page, then using PageGetExactFreeSpace is not doing justice in case of
heap page, because we wi
On Fri, 23 Aug 2024 at 10:54, shawn wang wrote:
> Hi hackers,
>
> Currently, all processes in PostgreSQL actually use malloc to allocate
> and free memory. In the case of long connections where business queries are
> executed over extended periods, the distribution of memory can become
> extremel
On 21/8/2024 16:52, Alexander Korotkov wrote:
/* Only operator clauses scan match */
Should it be:
/* Only operator clauses can match */
?
Corrected, thanks.
I found one more: /* Only operator clauses scan match */ - in the
second patch.
Also I propose:
- “might match to the index as whole”
On Tue, Aug 20, 2024 at 9:29 PM Amit Kapila wrote:
>
> On Tue, Aug 20, 2024 at 5:55 PM Masahiko Sawada wrote:
> >
> > On Fri, Aug 16, 2024 at 12:22 AM Shlok Kyal
> > wrote:
> > >
> >
> > Thank you for testing the patch!
> >
> > I'm slightly hesitant to add a test under src/test/subscription sin
On Fri, 23 Aug 2024 at 11:01, Frédéric Yhuel
wrote:
>
>
> On 8/22/24 21:56, Rafia Sabih wrote:
> > I agree with the approach here.
> > A minor comment here is to change the comments in code referring to the
> > PageGetHeapFreeSpace.
>
> Thank you Rafia. Here is a v2 patch.
>
> I've also added thi
Thanks for the feedback Melih,
On Thu, 22 Aug 2024 at 21:26, Melih Mutlu wrote:
> It seems like extended_relation_expr allows "tablename *" syntax too. That
> should be added in docs as well. (Same for VACUUM doc)
I had included it in the parameter description but had missed it from
the synopsi
Hi,
I would like to update something about this idea.
I attached a new
patch 0003-Imporve-pg_re_throw-check-if-sigjmp_buf-is-valid-and.patch.
Not too many updates in it:
- replace the 'ereport' with Assert
- besides checking the PG_exception_stack->magic, also check the address of
PG_exception_sta
drop table if exists gtest_err_1 cascade;
CREATE TABLE gtest_err_1 (
a int PRIMARY KEY generated by default as identity,
b int GENERATED ALWAYS AS (22),
d int default 22);
create view gtest_err_1_v as select * from gtest_err_1;
SELECT events & 4 != 0 AS can_upd, events & 8 != 0 AS can_ins,events &
On 8/22/24 21:56, Rafia Sabih wrote:
I agree with the approach here.
A minor comment here is to change the comments in code referring to the
PageGetHeapFreeSpace.
Thank you Rafia. Here is a v2 patch.
I've also added this to the commit message:
Also, PageGetHeapFreeSpace() will return zero
Hi hackers,
Currently, all processes in PostgreSQL actually use malloc to allocate and
free memory. In the case of long connections where business queries are
executed over extended periods, the distribution of memory can become
extremely complex.
Under certain circumstances, a common issue in me
On Fri, Aug 23, 2024 at 11:56 AM Tom Lane wrote:
> Richard Guo writes:
> > I agree that it’s always desirable to postpone work from path-creation
> > time to plan-creation time. In this case, however, it’s a little
> > different. The projection step could actually be avoided from the
> > start
Hi,
On Wed, Mar 08, 2023 at 04:34:38PM -0800, Andres Freund wrote:
> On 2023-03-08 12:55:34 +0100, Drouvot, Bertrand wrote:
> > - pg_stat_io is "global" across all sessions. So, even if one session is
> > doing some "testing" and needs to turn track_io_timing on, then it
> > is even not sure it's
80 matches
Mail list logo
