On Sat, Jul 27, 2024 at 11:42 PM David Rowley wrote:
>
> I didn't test to see where that's coming from, but I did test the two
> attached .c files. int.c uses the 0 - (unsigned int) var method and
> int2.c uses (unsigned int) (-var). Using clang and -ftrapv, I get:
>
> $ clang int.c -o int -O2 -
On Sun, 28 Jul 2024 at 13:10, Joseph Koshakow wrote:
>
> On Sat, Jul 27, 2024 at 8:00 PM David Rowley wrote:
> > What if we spelt it out the same way as pg_lltoa() does?
> >
> > i.e: uint64 usize = size < 0 ? 0 - (uint64) size : (uint64) size;
>
> My understanding of pg_lltoa() is that it produce
On Saturday, July 27, 2024, Melanie Plageman
wrote:
>
>
> Yes, the only thing that is important is having two rounds of index
> vacuuming and having one tuple with a value matching my cursor
> condition before the first index vacuum and one after. What do you
> mean update only the last few tuples
On Sun, Jul 28, 2024 at 10:48 AM Tom Lane wrote:
> Interesting. Maybe meson is over-aggressively trying to run these
> test suites in parallel?
Hypothesis: NTFS might not be as good at linking/unlinking lots of
files concurrently due to forced synchronous I/O, causing queuing?
That's what [1] w
On Sat, Jul 27, 2024 at 8:00 PM David Rowley wrote:
>
> On Sun, 28 Jul 2024 at 11:06, Joseph Koshakow wrote:
>> > + uint64 usize = size < 0 ? (uint64) (-size) : (uint64) size;
>>
>> I think that the explicit test for PG_INT64_MIN is still required. If
>> `size` is equal to PG_INT64_MIN then `-siz
On Sun, 28 Jul 2024 at 11:06, Joseph Koshakow wrote:
> > + uint64 usize = size < 0 ? (uint64) (-size) : (uint64) size;
>
> I think that the explicit test for PG_INT64_MIN is still required. If
> `size` is equal to PG_INT64_MIN then `-size` will overflow. You end up
> with the correct behavior if `
On Sat, Jul 27, 2024 at 6:28 PM David Rowley wrote:
>
> On Sun, 28 Jul 2024 at 07:18, Joseph Koshakow wrote:
>> Attached is a patch that resolves an overflow in pg_size_pretty() that
>> resulted in unexpected behavior when PG_INT64_MIN was passed in as an
>> argument.
>
> Could we just fix this m
> Yes, sorry, I should have said one can not create a with hold portal using
> the BIND command
Ok.
It would be possible to add a new parameter to the BIND command to
create such a portal. But it needs some changes to the existing
protocol definition and requires protocol version up, which is a m
Andrew Dunstan writes:
> On 2024-07-27 Sa 10:20 AM, Tom Lane wrote:
>> Just to add some more fuel to the fire: I do *not* observe such an
>> effect on my own animals.
> The culprit appears to be meson. When I tested running crake with
> "using_meson => 0" I got results in line with yours.
Inter
On 2024-07-27 Sa 10:20 AM, Tom Lane wrote:
Andrew Dunstan writes:
As part of its 002_pgupgrade.pl, the pg_upgrade tests do a rerun of the
normal regression tests. That in itself is sad, but what concerns me
here is why it's so much slower than the regular run? This is apparent
everywhere (e.g
On Sun, 28 Jul 2024 at 07:18, Joseph Koshakow wrote:
> Attached is a patch that resolves an overflow in pg_size_pretty() that
> resulted in unexpected behavior when PG_INT64_MIN was passed in as an
> argument.
Could we just fix this more simply by assigning the absolute value of
the signed variab
On 7/26/24 11:00 PM, Jeff Davis wrote:
Results (in ms):
"C" "libc_c" overhead
master:6350 7855 24%
v4-0001: 6091 6324 4%
I got more overhead in my quick benchmarking when I ran the same
benchmark. Also tried your idea with caching the last loo
On Sat, Jul 27, 2024 at 3:18 PM Joseph Koshakow wrote:
>
> `SELECT -9223372036854775808::bigint` results in an out of range error,
> even though `-9223372036854775808` can fit in a `bigint` and
> `SELECT pg_typeof(-9223372036854775808)` returns `bigint`. That's why
> the `::bigint` cast is omitted
rebased
--
nathan
>From 61513f744012c2b9b59085ce8c4a960da9e56ee7 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Sat, 22 Jun 2024 15:05:44 -0500
Subject: [PATCH v9 1/1] allow changing autovacuum_max_workers without
restarting
---
doc/src/sgml/config.sgml | 28 ++-
On 2024-07-26 Fr 1:46 PM, Masahiko Sawada wrote:
On Thu, Jul 25, 2024 at 6:52 PM Andrew Dunstan wrote:
On 2024-07-25 Th 3:40 PM, Masahiko Sawada wrote:
On Thu, Jul 25, 2024 at 11:06 AM Masahiko Sawada wrote:
On Thu, Jul 25, 2024 at 10:56 AM Andrew Dunstan wrote:
On 2024-07-23 Tu 6:59 PM,
jian he writes:
> On Fri, Jul 26, 2024 at 10:40 PM Tom Lane wrote:
>> Hmm, yeah, you're right. I didn't want to write two separate
>> synopses there, but maybe there's no choice.
> Now the output is
> It has the syntax regexp_replace(string, pattern, replacement [, flags
> ]) and regexp_replace
Dave Cramer writes:
> On Sat, 27 Jul 2024 at 01:55, Tatsuo Ishii wrote:
>>> So while the API's are "virtually" identical AFAICT there is no way to
>>> create a "WITH HOLD" portal ?
> Yes, sorry, I should have said one can not create a with hold portal using
> the BIND command
Yeah. The two API
Hi all,
Attached is a patch that resolves an overflow in pg_size_pretty() that
resulted in unexpected behavior when PG_INT64_MIN was passed in as an
argument.
The pg_abs_s64() helper function is extracted and simplified from patch
0001 from [0]. I didn't add similar functions for other sized inte
On 7/26/24 10:35 PM, Jeff Davis wrote:
database_ctype_is_c refers to the LC_CTYPE environment of the database
-- pg_database.datctype. default_locale.ctype_is_c is the ctype of the
database's default collation.
Confusing, I know, but it matters for a few things that still depend on
the LC_CTYPE,
Hello,
I hope this message finds you well. I am currently working on a PostgreSQL
extension and have encountered an issue where a static pointer becomes null
between different AM routines. My problem is as follows:
I am working with a few AM routines, specifically “ambuild” and “amrescan”.
Dur
Dave Cramer
On Sat, 27 Jul 2024 at 01:55, Tatsuo Ishii wrote:
> > So while the API's are "virtually" identical AFAICT there is no way to
> > create a "WITH HOLD" portal ?
>
> I am not sure if I fully understand your question but I think you can
> create a portal with "WITH HOLD" option.
>
> BEG
On Thu, 2024-07-25 at 13:29 -0700, Jeff Davis wrote:
> it may be a good idea to version collation and ctype
> separately. The ctype version is, more or less, the Unicode version,
> and we know what that is for the builtin provider as well as ICU.
Attached a rough patch for the purposes of discussi
Andrew Dunstan writes:
> As part of its 002_pgupgrade.pl, the pg_upgrade tests do a rerun of the
> normal regression tests. That in itself is sad, but what concerns me
> here is why it's so much slower than the regular run? This is apparent
> everywhere (e.g. on crake the standard run takes abo
As part of its 002_pgupgrade.pl, the pg_upgrade tests do a rerun of the
normal regression tests. That in itself is sad, but what concerns me
here is why it's so much slower than the regular run? This is apparent
everywhere (e.g. on crake the standard run takes about 30 to 90 s, but
pg_upgrad
On Wed, 24 Jul 2024 at 22:55, Heikki Linnakangas wrote:
>
> On 02/07/2024 07:49, David Rowley wrote:
> > I've attached a rebased set of patches. The previous set no longer applied.
>
> I looked briefly at the first patch. Seems reasonable.
>
> One little thing that caught my eye is that in popula
On 26/07/2024 23:01, Tristan Partin wrote:
Heikki asked me to take a look at this patchset for the commitfest.
Looks good to me.
Heikki, just be careful rebasing the first patch. You need to make sure
the newly set `required: false` gets carried forward.
Committed and backpatched to v16 and v1
On Thu, Jul 25, 2024 at 5:04 PM Alena Rybakina
wrote:
> To be honest, I have found a big problem in this patch - we try to perform
> the transformation every time we examime a column:
>
> for (indexcol = 0; indexcol < index->nkeycolumns; indexcol++) { ...
>
> }
>
> I have fixed it and moved the t
Hi!
Cloudberry DB (Greenplum fork) uses IMMV feature for AQUMV (auto query
use matview) feature, so i got interested in how it is implemented.
On Thu, 11 Jul 2024 at 09:24, Yugo NAGATA wrote:
>
> I updated the patch to bump up the version numbers in psql and pg_dump codes
> from 17 to 18.
Few su
28 matches
Mail list logo
