On Fri, Jun 28, 2024 at 05:36:25PM -0400, Melanie Plageman wrote:
> I've attached a WIP v11 streaming vacuum patch set here that is
> rebased over master (by Thomas), so that I could add a CF entry for
> it. It still has the problem with the extra WAL write and fsync calls
> investigated by Thomas
On Sun, Jul 7, 2024, at 13:28, Dean Rasheed wrote:
> The numeric round() and trunc() functions clamp the scale argument to
> the range between +/- NUMERIC_MAX_RESULT_SCALE, which is +/- 2000.
> That's a long way short of the actual allowed range of type numeric,
> so they produce incorrect results
On Sun, Jul 7, 2024, 7:44 AM Joel Jacobson wrote:
> On Sat, Jul 6, 2024, at 17:36, Dean Rasheed wrote:
> > In the numeric width_bucket() code, we currently do the following:
> ..
> > Instead, this can be done more simply and efficiently, using division
> > with truncation as follows:
> ..
> >
Hi feichanghong
Thanks for updating the patch ,I think could be configured as a GUC
parameter,PostgreSQL has too many static variables that are written to
death and explicitly stated in the code comments may later be designed as
parameters. Now that more and more applications that previously
On 2024-07-07 Su 7:28 AM, Andrew Dunstan wrote:
On 2024-07-07 Su 3:02 AM, Andres Freund wrote:
Hi,
While working on [1] I encountered the issue that, on github-actions,
010_pg_basebackup.pl fails on windows.
The reason for that is that github actions uses two drives, with
TMP/TEMP
located
On Sat, Jul 6, 2024, at 17:36, Dean Rasheed wrote:
> In the numeric width_bucket() code, we currently do the following:
..
> Instead, this can be done more simply and efficiently, using division
> with truncation as follows:
..
>
> Patch attached. I didn't bother with any new test cases, since
Hello everybody,
On 12.06.2024 20:13, Igor V.Gnatyuk wrote:
Hello.
Before the advent of procedures in PostgreSQL 11 that can manage
transactions, there could only be one transaction
in one statement. Hence the end of the transaction also meant the end
of the statement. Apparently, this is
The numeric round() and trunc() functions clamp the scale argument to
the range between +/- NUMERIC_MAX_RESULT_SCALE, which is +/- 2000.
That's a long way short of the actual allowed range of type numeric,
so they produce incorrect results when rounding/truncating more than
2000 digits before or
On 2024-07-07 Su 3:02 AM, Andres Freund wrote:
Hi,
While working on [1] I encountered the issue that, on github-actions,
010_pg_basebackup.pl fails on windows.
The reason for that is that github actions uses two drives, with TMP/TEMP
located on c:, the tested code on d:. This causes the
As part of making tuplestores faster [1], I noticed that in WindowAgg, when
we end one partition we call tuplestore_end() and then we do
tuplestore_begin_heap() again for the next partition in begin_partition()
and then go on to set up the tuplestore read pointers according to what's
required for
On 2024-07-07 Su 1:26 AM, Tom Lane wrote:
Andres Freund writes:
Do we want to support checking out with core.autocrlf?
-1. It would be a constant source of breakage, and you could never
expect that (for example) making a tarball from such a checkout
would match anyone else's results.
> On Fri, Jun 21, 2024 at 01:28:11PM +0900, Michael Paquier wrote:
> On Fri, Jun 21, 2024 at 01:09:10PM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier
> > wrote in
> >> * The kind IDs may change across restarts, meaning that any stats data
> >> associated
I think the period here should be a typo.
index 16b5803d388..af3b15e93df 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -185,7 +185,7 @@ typedef struct ComputeXidHorizonsResult
FullTransactionId latest_completed;
/*
-* The
Hi,
While working on [1] I encountered the issue that, on github-actions,
010_pg_basebackup.pl fails on windows.
The reason for that is that github actions uses two drives, with TMP/TEMP
located on c:, the tested code on d:. This causes the following code to fail:
# Create a temporary
Hi,
While working to address some of Dave's concerns at [1], I encountered the odd
issue of tests failing because postmaster not being allowed to open
pg_control. This did not happen for all tests, but for a lot of tests.
For example, the only output in
On 04/07/2024 3:45 pm, Yao Wang wrote:
Generally, the benefit of mksort is mainly from duplicated values and sort
keys: the more duplicated values and sort keys are, the bigger benefit it
gets.
...
1. Use distinct stats info of table to enable mksort
It's kind of heuristics: in optimizer,
Hi,
On 2024-07-07 01:26:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Do we want to support checking out with core.autocrlf?
>
> -1. It would be a constant source of breakage, and you could never
> expect that (for example) making a tarball from such a checkout
> would match anyone
Andres Freund writes:
> Do we want to support checking out with core.autocrlf?
-1. It would be a constant source of breakage, and you could never
expect that (for example) making a tarball from such a checkout
would match anyone else's results.
> If we do not want to support that, ISTM we
Hi,
Git on windows defaults to core.autocrlf being enabled. Which means
that a normal git clone will convert all lineendings in text files.
Unfortunately that causes a few tests to fail, at least:
test_json_parser/001_test_json_parser_incremental
test_json_parser/003_test_semantic
Richard:
Thanks for reviving this patch and for all of your work on it! Eager
aggregation pushdown will be beneficial for my work and I'm hoping to see
it land.
I was playing around with v9 of the patches and was specifically curious
about this previous statement...
>This patch also makes
On Thu, Jun 13, 2024 at 12:00 AM Alexander Lakhin
wrote:
> SELECT '[]'::jsonb -> -2147483648;
>
> #4 0x7efe232d67f3 in __GI_abort () at ./stdlib/abort.c:79
> #5 0x55e8fde9f211 in __negvsi2 ()
> #6 0x55e8fdcca62c in jsonb_array_element (fcinfo=0x55e8fec28220) at
jsonfuncs.c:948
>
>
On Tue, Apr 09, 2024 at 04:51:52PM +1200, Thomas Munro wrote:
> Here's a rebase. I decided against committing this for v17 in the
> end. There's not much wrong with it AFAIK, except perhaps an
> unprincipled chopping up of writes with large io_combine_limit due to
> simplistic flow control, and
>
> On Jul 6, 2024, at 12:51 PM, Noah Misch wrote:
> Behavior after that:
>
> -- 2 rows w/ seq scan, 0 rows w/ index scan
> SELECT 1 FROM t WHERE s ~ '[[:alpha:]]';
> SET enable_seqscan = off;
> SELECT 1 FROM t WHERE s ~ '[[:alpha:]]';
>
> -- ERROR: heap tuple (0,1) from table "t" lacks
Noah Misch writes:
> As a released feature, NORMALIZE() has a different set of remedies to choose
> from, and I'm not proposing one. I may have sidetracked this thread by
> talking about remedies without an agreement that pg_c_utf8 has a problem. My
> question for the PostgreSQL maintainers is
On Fri, Jul 05, 2024 at 02:38:45PM -0700, Jeff Davis wrote:
> 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
I wrote:
> One angle that ought to be considered is that some of this stuff may
> be flat-out bugs in 2.13.0. I see at
> https://gitlab.gnome.org/GNOME/libxml2/-/releases
> that both 2.13.1 and 2.13.2 contain fixes for "regressions" in 2.13.0.
> I'm disinclined to spend much effort on working
Reading through postmaster code, I spotted some refactoring
opportunities to make it slightly more readable.
Currently, when a child process exits, the postmaster first scans
through BackgroundWorkerList to see if it was a bgworker process. If not
found, it scans through the BackendList to
On Thu, Jun 13, 2024 at 12:00 AM Alexander Lakhin
wrote:
>
> And one more with array...
> CREATE TABLE t (ia int[]);
> INSERT INTO t(ia[2147483647:2147483647]) VALUES ('{}');
I've added another patch, 0003, to resolve this wrap-around. In fact I
discovered a bug that the following statement is
Erik Wienhold writes:
> On 2024-07-06 16:25 +0200, Tom Lane wrote:
>> Yeah, apparently --- I get what look like the same diffs with
>> libxml2 2.13.0 recently supplied by MacPorts. Grumble.
>> Somebody's going to have to look into that.
> Here's a patch that fixes just the xmlserialize and
On 2024-07-06 16:25 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > So, there must be breaking changes in 2.13.0:
> > https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.13.0
>
> Yeah, apparently --- I get what look like the same diffs with
> libxml2 2.13.0 recently supplied by MacPorts.
Hi!
I’m doing another iteration over the patchset.
PgStartLSN = GetXLogInsertRecPtr();
Should this be kind of RecoveryEndPtr? How is it expected to behave on Standby
in HA cluster, which was doing a crash recovery of 1y WALs in a day, then is in
startup for a year as a Hot Standby, and then is
In the numeric width_bucket() code, we currently do the following:
mul_var(_var, count_var, _var,
operand_var.dscale + count_var->dscale);
div_var(_var, _var, result_var,
select_div_scale(_var, _var), true);
if (cmp_var(result_var, count_var) >= 0)
Erik Wienhold writes:
> So, there must be breaking changes in 2.13.0:
> https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.13.0
Yeah, apparently --- I get what look like the same diffs with
libxml2 2.13.0 recently supplied by MacPorts. Grumble.
Somebody's going to have to look into that.
Hi,
On Fri, Jul 05, 2024 at 11:10:00AM +0530, Amit Kapila wrote:
> On Fri, Jun 28, 2024 at 6:30 PM Bertrand Drouvot
> wrote:
> >
> > On Fri, Jun 28, 2024 at 03:15:22PM +0530, Amit Kapila wrote:
> > > On Fri, Jun 28, 2024 at 12:55 PM Peter Smith
> > > wrote:
> > > >
> > >
> > > I don't know
> On 5 Jul 2024, at 23:46, Paul Jungwirth wrote:
>
> this commit adds support for all combinations of int2/int4/int8 for all five
> btree operators (=/>).
Looks like a nice feature to have.
Would it make sense to do something similar to float8? Or, perhaps, some other
types from
On 2024-07-06 11:57 +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
1eff8279d4 added memory/disk usage for materialize nodes in EXPLAIN
ANALYZE.
In the commit message:
> There are a few other executor node types that use tuplestores, so we
> could also consider adding these details to the EXPLAIN ANALYZE for
> those nodes too.
So I wanted to Add memory/disk usage
On Sat, Jul 6, 2024, at 11:34, Dean Rasheed wrote:
> On Fri, 5 Jul 2024 at 18:37, Joel Jacobson wrote:
>>
>> 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
>> 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 differences that caused some tests to fail can be
On Thu, Jun 27, 2024 at 1:11 AM Tom Lane wrote:
>
> David Rowley writes:
> > Maybe I'm slow on the uptake, but I've yet to see anything here where
> > time literals act in a special way DEFAULT constraints. This is why I
> > couldn't understand why we should be adding documentation about this
>
On Fri, 5 Jul 2024 at 18:37, Joel Jacobson wrote:
>
> 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
On Wed, Jun 19, 2024 at 10:55 AM Tender Wang wrote:
> Richard Guo 于2024年6月18日周二 17:24写道：
>> I updated the patch to include a check in consider_parallel_nestloop
>> ensuring that inner_cheapest_total is not parameterized by outerrel
>> before materializing it. I also tweaked the comments, test
> Perhaps Nitin was thinking of a scenario in which WAL hits are counted
> as hits on the same IOObject as shared buffer hits. Since this thread
> has been going on for awhile and we haven't recently had a schema
> overview, I could understand if there was some confusion
Yes. I was considering a
Hi,
I noticed that ALTER TABLE MERGE PARTITIONS and SPLIT PARTITION commands
always create new partitions in the default tablespace, regardless of
the parent's tablespace. However, the indexes of these new partitions inherit
the tablespaces of their parent indexes. This inconsistency seems odd.
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
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.
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
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
> *
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
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
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
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
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
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
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
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;
> " |
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
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
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
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
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.
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)
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
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
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.
>
>
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
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
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
>>
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
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
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
>
> 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
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
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
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
"=?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,
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
>
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
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
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
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
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
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
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
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
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
> >>
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
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
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.
501 - 600 of 171743 matches
Mail list logo
