On Sat, 6 Jul 2024 at 12:08, David Rowley wrote:
> I also had not intended that the buffile.c stuff would use the
> generation context. I'll need to fix that too, but I think I'll fix
> the GenerationRealloc() first.
I've pushed a fix for that now too.
David
On Sat, 6 Jul 2024 at 15:11, MARK CALLAGHAN wrote:
> On small servers I have at home I can reproduce the problem without
> concurrent queries and 17beta2 is 5% to 10% slower there.
>
> The SQL statement for the scan microbenchmark is:
> SELECT * from %s WHERE LENGTH(c) < 0
Can you share the CREA
I am seeking advice. For now I hope for a suggestion about changes from
17beta1 to 17beta2 that might cause the problem -- assuming there is a
problem, and not a mistake in my testing.
One of the sysbench microbenchmarks that I run does a table scan with a
WHERE clause that filters out all rows. T
On Fri, Jul 5, 2024 at 8:35 PM Amit Langote wrote:
> Please check the attached. I've also added lists as I
> remember you had proposed before to make the functions' descriptions a
> bit more readable -- I'm persuaded. :-)
>
json_exists
"Returns true if the SQL/JSON path_expression applied to t
Richard Guo writes:
> BTW, from catversion.h I read:
> * Another common reason for a catversion update is a change in parsetree
> * external representation, since serialized parsetrees appear in stored
> * rules and new-style SQL functions. Almost any change in primnodes.h or
> * parsenodes.
Thomas Munro writes:
> REL_14_STABLE and REL_15_STABLE have commit de8feb1f3, which turned on
> -Wcast-function-type, but don't have commit 101c37cd, which disabled
> -Wcast-function-type-strict as we agreed to do[1]. I noticed this on
> my local system that has clang 18 as compiler, but you can
On Thu, Jul 4, 2024 at 04:18:43PM +0200, Daniel Gustafsson wrote:
> > Searching for "cimarron postgres" returns
> > https://en.wikipedia.org/wiki/Illustra, which mentions a Cimarron Taylor
> > as one of Stonebraker's students, but I can't find anything else
> > relevant in a few minutes of searchi
On Wed, Jul 3, 2024 at 01:20:10PM +0200, Tomas Vondra wrote:
> > * Restartability - the initial version of the patch did not support stateful
> > restarts, a shutdown performed (or crash) before checksums were enabled
> > would
> > result in a need to start over from the beginning. This was deem
On Fri, Jul 5, 2024 at 5:51 AM Andres Freund wrote:
> On 2024-07-01 16:29:16 +0800, Richard Guo wrote:
> > Here is an updated version of this patchset. I've run pgindent for it,
> > and also tweaked the commit messages a bit.
> >
> > In principle, 0001 can be backpatched to all supported versions
On Sat, 6 Jul 2024 at 12:08, David Rowley wrote:
> The attached fixes the issue. I'll stare at it a bit more and try to
> decide if that's the best way to fix it.
I did that staring work and thought about arranging the code to reduce
the number of #ifdefs. In the end, I decided it was better to k
On Thu, Jul 4, 2024 at 6:02 PM Ashutosh Bapat
wrote:
> On Mon, Jul 1, 2024 at 1:59 PM Richard Guo wrote:
> > Here is an updated version of this patchset. I've run pgindent for it,
> > and also tweaked the commit messages a bit.
> >
> > In principle, 0001 can be backpatched to all supported versi
On Fri, Jul 5, 2024 at 8:44 PM Peter Geoghegan wrote:
> CREATE INDEX test4_idx ON test4 USING btree(((extract(year from d))::int4),n);
>
> This performs much better. Now I see "DEBUG: skipping 1 index
> attributes" when I run the query "EXPLAIN (ANALYZE, BUFFERS) SELECT
> COUNT(*) FROM test4 WHER
On Fri, Jul 5, 2024 at 7:04 AM Aleksander Alekseev
wrote:
> Test2 with "char" doesn't seem to benefit from the patch anymore
> (pretty sure it did in v1). It always chooses Parallel Seq Scans even
> if I change the condition to `WHERE n > 999_995_000` or `WHERE n =
> 999_997_362`. Is it an expecte
Hi,
REL_14_STABLE and REL_15_STABLE have commit de8feb1f3, which turned on
-Wcast-function-type, but don't have commit 101c37cd, which disabled
-Wcast-function-type-strict as we agreed to do[1]. I noticed this on
my local system that has clang 18 as compiler, but you can see it on
any build farm
On Sat, 6 Jul 2024 at 02:00, Alexander Lakhin wrote:
> CREATE TABLE t(f int, t int);
> INSERT INTO t VALUES (1, 1);
>
> WITH RECURSIVE sg(f, t) AS (
> SELECT * FROM t t1
> UNION ALL
> SELECT t2.* FROM t t2, sg WHERE t2.f = sg.t
> ) SEARCH DEPTH FIRST BY f, t SET seq
> SELECT * FROM sg;
> " | timeo
And pushed.
On 2024-07-04 22:18 +0200, Said Assemlal wrote:
> +1 for this feature.
Thanks!
> I noticed replacing the materialized view is blocking all reads. Is that
> expected ? Even if there is a unique index ?
That is expected because AccessExclusiveLock is acquired on the existing
matview. This is also
On Tue, 2 Jul 2024 at 13:48, David Rowley wrote:
>
> On Tue, 2 Jul 2024 at 02:43, Tom Lane wrote:
> > I'd be more excited about this discussion if I didn't think that
> > the chances of removing 'now'::timestamp are exactly zero. You
> > can't just delete useful decades-old features, whether the
On Fri, Jul 5, 2024 at 2:11 PM Bruce Momjian wrote:
>
> If I remove the 'now()' mention in the docs, patch attached, I am
> concerned people will be confused whether it is the removal of the
> single quotes or the use of "()" which causes insert-time evaluation,
> and they might try 'now()'.
>
>
On Thu, 2024-07-04 at 14:26 -0700, Noah Misch wrote:
> I think you're saying that if some Unicode update changes the results
> of a
> STABLE function but does not change the result of any IMMUTABLE
> function, we
> may as well import that update. Is that about right? If so, I
> agree.
If you are
On Fri, Jul 5, 2024 at 05:03:35PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Well, 'now()' certainly _looks_ like a function call, though it isn't.
> > The fact that 'now()'::timestamptz and 'now'::timestamptz generate
> > volatile results via a function call was my point.
>
> The only
On Fri, Jul 5, 2024 at 1:55 PM Bruce Momjian wrote:
> On Fri, Jul 5, 2024 at 04:50:32PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Also interestingly, "now" without quotes requires parentheses to make
> it
> > > a function call:
> >
> > I'm not sure why you find that surprising, or
Bruce Momjian writes:
> Well, 'now()' certainly _looks_ like a function call, though it isn't.
> The fact that 'now()'::timestamptz and 'now'::timestamptz generate
> volatile results via a function call was my point.
The only reason 'now()'::timestamptz works is that timestamptz_in
ignores irrel
On Fri, Jul 5, 2024 at 04:50:32PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Also interestingly, "now" without quotes requires parentheses to make it
> > a function call:
>
> I'm not sure why you find that surprising, or why you think that
> 'now()'::timestamptz is a function call. (Wel
On Fri, Jul 5, 2024 at 07:51:38PM +0200, Matthias van de Meent wrote:
> Hi,
>
> I noticed that PG17's release note for commit cafe10565 is "Allow psql
> connections to be canceled with control-C (Tristan Partin)", but this
> summary seems wrong to me.
>
> We already had ^C connection (query) can
Bruce Momjian writes:
> Also interestingly, "now" without quotes requires parentheses to make it
> a function call:
I'm not sure why you find that surprising, or why you think that
'now()'::timestamptz is a function call. (Well, it is a call of
timestamptz_in, but not of the SQL function now().)
On Mon, Jul 1, 2024 at 02:52:42PM +1200, David Rowley wrote:
> On Mon, 1 Jul 2024 at 13:41, David G. Johnston
> wrote:
> > I presume the relatively new atomic SQL functions pose a similar hazard.
>
> Do you have an example of this?
>
> > The fact that 'now()'::timestamp fails to fail doesn't he
Committed.
--
nathan
What part of commitfest should I put the current patch to: "SQL
Commands", "Miscellaneous" or something else? I can't figure it out.
--
With best regards,
Marat Bukharov
> Hi Marat,
>
> > V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP
>
> Thanks for the patch.
>
> Pleas
The patch in the attachment, compared to the previous one, adds a threshold for
using the bloom filter. The current ON_COMMITS_FILTER_THRESHOLD is set to 64,
which may not be the optimal value. Perhaps this threshold could be configured
as a GUC parameter?
Best Regards,
Fei Changhong
v1-0001-Opt
Hi Hackers,
I noticed that this query wasn't using my GiST index:
postgres=# create extension btree_gist;
CREATE EXTENSION
postgres=# create table t (id bigint, valid_at daterange, exclude using gist (id with =, valid_at
with &&));
CREATE TABLE
postgres=# explain select * from t where id = 5;
> On 5 Jul 2024, at 14:16, Michael Paquier wrote:
>
> On Mon, Jun 10, 2024 at 03:10:33PM +0900, Michael Paquier wrote:
>> OK, cool. I'll try to get that into the tree once v18 opens up.
>
> And I've spent more time on this one, and applied it to v18 after some
> slight tweaks. Please feel fr
Pavel Stehule writes:
> čt 4. 7. 2024 v 21:42 odesílatel Tom Lane napsal:
>> Here's a v2 that does it like that.
> I like it.
> - patching and compilation without any issue
> - check world passed
> I'll mark this as ready for commit
Pushed, thanks!
regards, tom lane
Thank you for your attention and suggestions.
> On Jul 6, 2024, at 00:15, Tom Lane wrote:
>
> writes:
>> PostgreSQL maintains a list of temporary tables for 'on commit
>> drop/delete rows' via an on_commits list in the session. Once a
>> transaction accesses a temp table or namespace, the
>> XA
Hi,
I noticed that PG17's release note for commit cafe10565 is "Allow psql
connections to be canceled with control-C (Tristan Partin)", but this
summary seems wrong to me.
We already had ^C connection (query) cancellation for quite some time
before this patch. What's new with that patch, is that
On Fri, Jul 5, 2024, at 18:42, Joel Jacobson wrote:
> Very nice, v7-optimize-numeric-mul_var-small-var1-arbitrary-var2.patch
> is now the winner on all my CPUs:
I thought it would be interesting to also measure the isolated effect
on just numeric_mul() without the query overhead.
Included var1ndi
On Sun, Jun 30, 2024 at 09:42:19PM +,
fujii.y...@df.mitsubishielectric.co.jp wrote:
> On Mon, Jun 24, 2024 at 6:09?PM Jelte Fennema-Nio wrote:
> > 4. Related to 3, I think it would be good to have some tests of
> > PARTIAL_AGGREGATE that don't involve postgres_fdw at all. I also
> > spotted s
On Fri, 2024-07-05 at 13:55 +0200, Daniel Verite wrote:
> When these versions get bumped, it seems like packagers could stick
> to
> previous versions by just overriding these.
That's an interesting point. It's actually easier for a packager to pin
Unicode to a specific version than to pin libc to
>
> A more portable approach which could be to continue using nanosleep and
> add checks to ensure that nanosleep exists whenever
> it goes past an absolute time. This was suggested by Bertrand in an offline
> conversation. I am not yet fully convinced of this idea, but posting the patch
> that im
With 50 indexes and 10 parallel workers I can see things like:2024-07-02 08:22:23.789 UTC [2189616] LOG: expected 1.00, actual 239.3783682024-07-02 08:22:24.575 UTC [2189616] LOG: expected 0.10, actual 224.3317372024-07-02 08:22:25.363 UTC [2189616] LOG: expected 1.30, actual 230.462
Attached patch teaches nbtree backwards scans to avoid needlessly
relocking a previously read page/buffer at the point where we need to
consider reading the next page (the page to the left).
Currently, we do this regardless of whether or not we already decided
to end the scan, back when we read th
On Fri, Jul 5, 2024, at 17:41, Dean Rasheed wrote:
> On Fri, 5 Jul 2024 at 12:56, Joel Jacobson wrote:
>>
>> Interesting you got so bad bench results for v6-mul_var_int64.patch
>> for var1ndigits=4, that patch is actually the winner on AMD Ryzen 9 7950X3D.
>
> Interesting.
I remeasured just to be
"=?ISO-8859-1?B?ZmVpY2hhbmdob25n?=" writes:
> PostgreSQL maintains a list of temporary tables for 'on commit
> drop/delete rows' via an on_commits list in the session. Once a
> transaction accesses a temp table or namespace, the
> XACT_FLAGS_ACCESSEDTEMPNAMESPACE flag is set. Before committing, th
On Fri, 5 Jul 2024 at 12:56, Joel Jacobson wrote:
>
> Interesting you got so bad bench results for v6-mul_var_int64.patch
> for var1ndigits=4, that patch is actually the winner on AMD Ryzen 9 7950X3D.
Interesting.
> On Intel Core i9-14900K the winner is
> v6-optimize-numeric-mul_var-small-var1-
Hi hackers,
# Background
PostgreSQL maintains a list of temporary tables for 'on commit
drop/delete rows' via an on_commits list in the session. Once a
transaction accesses a temp table or namespace, the
XACT_FLAGS_ACCESSEDTEMPNAMESPACE flag is set. Before committing, the
PreCommit_on_commit_a
On Fri, Jul 05, 2024 at 05:24:42PM +0800, 杨伯宇(长堂) wrote:
>> > So, I'm thinking, why not add a "--skip-check" option in pg_upgrade to
>> > skip it?
>> > See "1-Skip_Compatibility_Check_v1.patch".
>>
>> How would a user know that nothing has changed in the cluster between running
>> the check and r
On 2024-07-05 15:33 +0200, Frank Streitzig wrote:
> My system is a Arch Linux.
> I get after upgrade the libxml2 package (from 2.12.7-1 to 2.13.1-1)
> test errors for xml:
>
> not ok 202 + xml 1464 ms
> [...snip...]
> # 1 of 222 tests failed.
> # The differen
I wrote:
>
> I suggest assigning values
> bufferusage.shared_blks_read + bufferusage.local_blks_read
> and
> bufferusage.shared_blks_dirtied + bufferusage.local_blks_dirtied
> to new variables and using them. This would keep the changed lines within
> the 80 symbols limit, and make the code more r
Hi Anthonin,
I suggest assigning values
bufferusage.shared_blks_read + bufferusage.local_blks_read
and
bufferusage.shared_blks_dirtied + bufferusage.local_blks_dirtied
to new variables and using them. This would keep the changed lines within
the 80 symbols limit, and make the code more readable ov
On 02.07.24 18:02, Jim Jones wrote:
> It basically does the following:
>
> * When casting an XML value to a SQL data type, XML values containing
> XSD literals will be converted to their equivalent SQL data type.
> * When casting from a SQL data type to XML, the cast operand will be
> translated t
Hi Kuroda-san,
Thank you very much for the patch. In general, it seem to work well for me, but
there seems to be a memory access problem in libpqrcv_alter_slot ->
quote_identifier in case of NULL slot_name. It happens, if the two_phase option
is altered on a subscription without slot. I think,
05.07.2024 07:57, David Rowley wrote:
Thanks for the report. I've just pushed a fix in 53abb1e0e.
Thank you, David!
Please look at another anomaly introduced with 590b045c3:
echo "
CREATE TABLE t(f int, t int);
INSERT INTO t VALUES (1, 1);
WITH RECURSIVE sg(f, t) AS (
SELECT * FROM t t1
UNION
Hi
čt 4. 7. 2024 v 21:42 odesílatel Tom Lane napsal:
> I wrote:
> > Pavel Stehule writes:
> >> PLpgSQL uses more often function signature
> >> (2024-07-04 19:49:20) postgres=# select bx(0);
> >> ERROR: division by zero
> >> CONTEXT: PL/pgSQL function fx(integer) line 1 at RETURN
> >> PL/pgSQL
Hello hackers,
i compile postgresql just for fun.
My system is a Arch Linux.
I get after upgrade the libxml2 package (from 2.12.7-1 to 2.13.1-1) test errors
for xml:
---
...
ok 200 + largeobject 553 ms
ok 201 + with 8
Op 7/5/24 om 14:35 schreef Amit Langote:
Hi Jian,
Thanks for the reviews.
> [v3-0001-SQL-JSON-Various-improvements-to-SQL-JSON-query-f.patch]
i.e., from the patch for doc/src/sgml/func.sgml
Small changes:
4x:
'a SQL' should be
'an SQL'
('a SQL' does never occur in the docs; it's alwa
On 05/07/2024 14:07, vignesh C wrote:
On Thu, 4 Jul 2024 at 16:52, Heikki Linnakangas wrote:
I'm don't quite understand the problem we're trying to fix:
Currently the launcher's latch is used for the following: a) worker
process attach b) worker process exit and c) subscription creation.
Sin
On Tue, Oct 24, 2023 at 8:48 PM Devrim Gündüz wrote:
> I'm seeing an issue after upgrading from 12.13 to 15.4. This happens
> when we run a query against a foreign table (fdw on the same instance to
> a different database) -- but does not appear when we get rid of
> postgres_fdw:
>
> ERROR: curso
On 2024-07-04 Th 6:22 AM, Mohab Yaser wrote:
can you send me a link to download this version on windows as I didn't
find anything other than the one I already have downloaded
On Thu, Jul 4, 2024 at 1:21 PM Aleksander Alekseev
wrote:
Hi,
> While I was trying to install PostgreSQL f
Hi Jian,
Thanks for the reviews.
On Wed, Jul 3, 2024 at 11:15 AM jian he wrote:
> Overall, I found this approach makes the synopsis scattered, it's not
> easy to see the full picture.
> for example:
> ```
> JSON_VALUE ( context_item, path_expression [variable_definitions]
> [return_type] [on_emp
On Fri, 5 Jul 2024 at 09:46, Peter Smith wrote:
>
> Hi Vignesh.
>
> After applying the v20240703-0003 patch, I was always getting errors
> when running the subscription TAP tests.
>
> # +++ tap check in src/test/subscription +++
> t/001_rep_changes.pl ... ok
> t/002_types.pl ..
On Tue, Jul 2, 2024 at 10:59 AM Peter Smith wrote:
>
> Hi Shubham,
>
> As you can see, most of my recent review comments for patch 0001 are
> only cosmetic nitpicks. But, there is still one long-unanswered design
> question from a month ago [1, #G.2]
>
> A lot of the patch code of pgoutput.c and p
On Thu, Jul 4, 2024, at 20:43, Dean Rasheed wrote:
> On Wed, 3 Jul 2024 at 21:45, Joel Jacobson wrote:
>>
>> > On Wed, Jul 3, 2024, at 20:57, Dean Rasheed wrote:
>> >> I wouldn't expect it to ever be off by more than 1
>> >
>> > OK, so then the cases I found where it was off by 2 for the mul_var_i
Noah Misch wrote:
> > I don't think the builtin locale provider is any different in this respect
> > from the other providers: The locale data might change and there is a
> > version mechanism to track that. We don't prevent pg_upgrade in scenarios
> > like that for other providers.
>
>
On Mon, Jul 1, 2024 at 1:17 PM Ajin Cherian wrote:
>
>
>
> On Thu, Jun 27, 2024 at 1:14 PM Nisha Moond wrote:
>>
>> Please find the attached 'patch0003', which implements conflict
>> resolutions according to the global resolver settings.
>>
>> Summary of Conflict Resolutions Implemented in 'patc
On Fri, Jul 5, 2024 at 2:23 PM Amit Kapila wrote:
>
> On Fri, Jul 5, 2024 at 11:58 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 4, 2024 at 5:37 PM Amit Kapila wrote:
> > > > So, the situation will be the same. We can even
> > > > > decide to spill the data to files if the decision is that we need
Hi,
> I have committed the change of buildtype to debugoptimized.
There is still a warning previously reported by Melanie:
```
[1391/1944] Compiling C object src/pl/plpgsql/src/plpgsql.so.p/pl_exec.c.o
In file included from ../src/include/access/htup_details.h:22,
from ../src/pl
On Thu, 4 Jul 2024 at 16:52, Heikki Linnakangas wrote:
>
> I'm don't quite understand the problem we're trying to fix:
>
> > Currently the launcher's latch is used for the following: a) worker
> > process attach b) worker process exit and c) subscription creation.
> > Since this same latch is used
Hi Peter,
> It looks like the queries you posted have a kind of adversarial
> quality to them, as if they were designed to confuse the
> implementation. Was it intentional?
To some extent. I merely wrote several queries that I would expect
should benefit from skip scans. Since I didn't look at th
Hello Andres,
12.03.2023 02:41, Andres Freund wrote:
CI now finished the tests as well:
https://cirrus-ci.com/build/6675457702100992
So I'll go ahead and push that.
As I mentioned at [1], `meson test` fails on Windows x86 platform during
the test pg_amcheck/004_verify_heapam (I'm using VS 202
Dear Sawada-san,
> The parallel vacuum we have today supports only for index vacuuming.
> Therefore, while multiple workers can work on different indexes in
> parallel, the heap table is always processed by the single process.
> I'd like to propose $subject, which enables us to have multiple
> wor
> > So, I'm thinking, why not add a "--skip-check" option in pg_upgrade to skip
> > it?
> > See "1-Skip_Compatibility_Check_v1.patch".
>
> How would a user know that nothing has changed in the cluster between running
> the check and running the upgrade with a skipped check? Considering how
> comp
On Mon, Jun 10, 2024 at 03:10:33PM +0900, Michael Paquier wrote:
> OK, cool. I'll try to get that into the tree once v18 opens up.
And I've spent more time on this one, and applied it to v18 after some
slight tweaks. Please feel free to re-post your tests with
multixacts, Andrey.
--
Michael
si
Dear Amit,
Sorry, I forgot to say one content.
> > But that is not a good reason for this operation to stop workers
> > first. Instead, we should prohibit this operation if any worker is
> > present. The reason is that there is always a chance that if any
> > worker is alive, it can prepare a new
On Fri, Jul 5, 2024 at 11:58 AM Dilip Kumar wrote:
>
> On Thu, Jul 4, 2024 at 5:37 PM Amit Kapila wrote:
> > > So, the situation will be the same. We can even
> > > > decide to spill the data to files if the decision is that we need to
> > > > wait to avoid network buffer-fill situations. But no
On Fri, Jul 5, 2024, at 01:18, Michael Paquier wrote:
> I would still stick to only one function, with arguments coming from
> scanning pg_[sh]depend.
>
>> I found some code in aclchk.c on line 4452-4468 that seems useful,
>> but not sure. Maybe there is some other existing code that is better
>> a
On 04/07/2024 23:20, Andres Freund wrote:
On 2024-07-04 01:54:18 +0300, Heikki Linnakangas wrote:
I believe that was just an oversight. Trivial patch attached.
Oops. Yes, I clearly should have used dlist_container() here.
Committed, thanks.
--
Heikki Linnakangas
Neon (https://neon.tech)
> On 5 Jul 2024, at 09:12, 杨伯宇(长堂) wrote:
> 1: Skip Compatibility Check In "pg_upgrade"
> =
> Concisely, we've got several databases, each with a million-plus tables.
> Running the compatibility check before pg_dump can eat up like half an hour.
> If I
Here are my review comments for v14-0002.
==
src/backend/replication/logical/tablesync.c
make_copy_attnamelist:
nitpick - remove excessive parentheses in palloc0 call.
nitpick - Code is fine AFAICT except it's not immediately obvious
localgenlist is indexed by the *remote* attribute number.
On Wed, 3 Jul 2024 at 01:08, Melih Mutlu wrote:
> An example query to get total used bytes including children by using level
> info would look like:
>
> WITH contexts AS (
> SELECT * FROM pg_backend_memory_contexts
> )
> SELECT sum(total_bytes)
> FROM contexts
> WHERE path[( SELECT level+1 FROM c
On 2024-07-05 12:59, Fujii Masao wrote:
On 2024/07/04 12:05, torikoshia wrote:
I'm going to update it after discussing the option format as described
below.
Thanks!
I agree that it's possible to use only REJECT_LIMIT without ON_ERROR.
I also think it's easy to understand that REJECT_LIMIT=0
Hello postgres hackers:
I am recently working on speeding up pg_upgrade for database with over a
million tables and would like to share some (maybe) optimizeable or
interesting findings.
1: Skip Compatibility Check In "pg_upgrade"
=
Concisely, we've got
81 matches
Mail list logo
