Re: Fix overflow in pg_size_pretty

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

Re: Fix overflow in pg_size_pretty

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

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

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

Re: why is pg_upgrade's regression run so slow?

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]

Re: Fix overflow in pg_size_pretty

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

Re: Fix overflow in pg_size_pretty

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

Re: Fix overflow in pg_size_pretty

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

Re: Protocol question regarding Portal vs Cursor

> 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

Re: why is pg_upgrade's regression run so slow?

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.

Re: why is pg_upgrade's regression run so slow?

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

Re: Fix overflow in pg_size_pretty

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

Re: Speed up collation cache

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

Re: Fix overflow in pg_size_pretty

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

Re: allow changing autovacuum_max_workers without restarting

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 ++-

Re: xid_wraparound tests intermittent failure.

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

Re: add function argument names to regex* functions.

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

Re: Protocol question regarding Portal vs Cursor

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

Re: tiny step toward threading: reduce dependence on setlocale()

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

Re: Protocol question regarding Portal vs Cursor

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. > >

Re: [18] separate collation and ctype versions, and cleanup of pg_database locale fields

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

Re: why is pg_upgrade's regression run so slow?

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

Re: Speed up JSON escape processing with SIMD plus other optimisations

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

Re: Building with meson on NixOS/nixpkgs

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

Re: POC, WIP: OR-clause support for indexes

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

Re: Incremental View Maintenance, take 2

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

Re: Help Needed with Including External SQL Script in Extension Script

On Friday, July 26, 2024, Ayush Vatsa wrote: > > I wanted to modify the SQL script of an extension by creating multiple > objects within it. > My aim is to make minimal changes to the existing script. To achieve this, > I have created an > external script and am attempting to run it within the

Re: Things I don't like about \du's "Attributes" column

On 23.07.2024 15:53, Robert Haas wrote: On Mon, Jul 22, 2024 at 5:19 PM Pavel Luzanov wrote: Visible but inaccessible objects in system catalogs increase the volume of command output unnecessarily. Why do I need to know the list of all schemas in the database if I only have access to the

Re: Protocol question regarding Portal vs Cursor

> 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. BEGIN; DECLARE c CURSOR WITH HOLD FOR SELECT * FROM generate_series(1,10); (of

Re: pg_attribute.atttypmod for interval type

Greg Rychlewski writes: > My question is: how are the values meant to be interpreted for interval > types? Thanks very much for your help. Interval typmods include a fractional-seconds-precision field as well as a bitmask indicating the allowed interval fields (per the SQL standard's weird

Re: pg_upgrade failing for 200+ million Large Objects

Alexander Korotkov writes: > J4F, I have an idea to count number of ';' sings and use it for > transaction size counter, since it is as upper bound estimate of > number of SQL commands :-) Hmm ... that's not a completely silly idea. Let's keep it in the back pocket in case we can't easily

Re: pg_upgrade failing for 200+ million Large Objects

On Sat, Jul 27, 2024 at 2:06 AM Tom Lane wrote: > Alexander Korotkov writes: > > On Sat, Jul 27, 2024 at 1:37 AM Tom Lane wrote: > >> It's fairly easy to fix things so that this example doesn't cause > >> that to happen: we just need to issue these updates as one command > >> not N commands per

Re: add function argument names to regex* functions.

On Fri, Jul 26, 2024 at 10:40 PM Tom Lane wrote: > > jian he writes: > > On Fri, Jul 26, 2024 at 10:17 PM Tom Lane wrote: > >> AFAICS, that one is correct, so I left it alone. (I didn't try to > >> merge the table's two entries into one like that, though.) > > > regexp_replace(string, pattern,

Re: CREATE OR REPLACE MATERIALIZED VIEW

On 2024-07-12 16:49 +0200, Said Assemlal wrote: > > My initial idea, while writing the patch, was that one could replace the > > matview without populating it and then run the concurrent refresh, like > > this: > > > > CREATE OR REPLACE MATERIALIZED VIEW foo AS ... WITH NO DATA; > >

Re: MAINTAIN privilege -- what do we need to un-revert it?

Hello, Thank you for looking. On Fri, 2024-07-26 at 12:26 +0900, Yugo Nagata wrote: > Since this commit, matviews are no longer handled in > ExecCreateTableAs, so the > following error message has not to consider materialized view cases, > and can be made simple. > >     /* SELECT should

Re: pg_upgrade failing for 200+ million Large Objects

Alexander Korotkov writes: > On Sat, Jul 27, 2024 at 1:37 AM Tom Lane wrote: >> It's fairly easy to fix things so that this example doesn't cause >> that to happen: we just need to issue these updates as one command >> not N commands per table. > I was thinking about counting actual number of

Re: pg_upgrade failing for 200+ million Large Objects

On Sat, Jul 27, 2024 at 1:37 AM Tom Lane wrote: > Justin Pryzby writes: > > On Fri, Jul 26, 2024 at 10:53:30PM +0300, Alexander Korotkov wrote: > >> It would be nice to identify such cases and check which memory contexts are > >> growing and why. > > > I reproduced the problem with this schema:

Re: pg_upgrade failing for 200+ million Large Objects

Justin Pryzby writes: > On Fri, Jul 26, 2024 at 10:53:30PM +0300, Alexander Korotkov wrote: >> It would be nice to identify such cases and check which memory contexts are >> growing and why. > I reproduced the problem with this schema: > SELECT format('CREATE TABLE p(i int, %s) PARTITION BY

Re: query_id, pg_stat_activity, extended query protocol

On Fri, Jul 26, 2024 at 02:39:41PM +0200, Anthonin Bonnefoy wrote: > For the tests, there are limited possibilities to check whether a > query_id has been set correctly. > - Checking pg_stat_activity is not possible in the regress tests as > you need a second session to check the reported

Re: Use pgBufferUsage for block reporting in analyze

On Wed, Jul 24, 2024 at 1:58 AM Anthonin Bonnefoy wrote: > > On Mon, Jul 22, 2024 at 10:59 PM Masahiko Sawada > wrote: > > The first line would vary depending on whether an autovacuum worker or > > not. And the above suggestion includes a change of term "row" to > > "tuple" for better

Re: Support LIKE with nondeterministic collations

On Thu, Jun 27, 2024 at 11:31 PM Peter Eisentraut wrote: > Here is an updated patch for this. I took a look at this. I added some tests and found a few that give the wrong result (I believe). The new tests are included in the attached patch, along with the results I expect. Here are the

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Fri, Jul 26, 2024 at 11:50:48PM +0300, Alexander Korotkov wrote: > Thanks to everybody for working on this. It's pity I didn't notice > this is v17 open item on me. Sorry for this. No problem. I've just applied now the remaining pieces down to 17. -- Michael signature.asc Description: PGP

Re: pg_upgrade failing for 200+ million Large Objects

On Fri, Jul 26, 2024 at 11:36 PM Justin Pryzby wrote: > On Wed, Jul 24, 2024 at 09:17:51AM -0500, Justin Pryzby wrote: > > With partitioning, we have a lot of tables, some of them wide (126 > > partitioned tables, 8942 childs, total 1019315 columns). > > On Fri, Jul 26, 2024 at 10:53:30PM +0300,

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Wed, Jul 24, 2024 at 3:43 AM John Naylor wrote: > > On Wed, Jul 24, 2024 at 5:40 AM Masahiko Sawada wrote: > > > Without MEMORY_CONTEXT_CHECK, if size is 16 bytes, required_size is > > also 16 bytes as it's already 8-byte aligned and Bump_CHUNKHDRSZ is 0. > > On the other hand with

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Wed, Jul 24, 2024 at 8:19 AM John Naylor wrote: > > On Wed, Jul 24, 2024 at 2:42 PM John Naylor wrote: > > As for lowering the limit, we've experimented with 256kB here: > > > > https://www.postgresql.org/message-id/canwcazzutvz3lsypauyqvzcezxz7qe+9ntnhgyzdtwxpul+...@mail.gmail.com > > > > As

Re: Speed up collation cache

On Thu, 2024-06-20 at 17:07 +0700, John Naylor wrote: > On Sat, Jun 15, 2024 at 6:46 AM Jeff Davis wrote: > > Attached is a patch to use simplehash.h instead, which speeds > > things up > > enough to make them fairly close (from around 15% slower to around > > 8%). > > +#define SH_HASH_KEY(tb,

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

On Fri, Jul 26, 2024 at 5:38 PM Robert Haas wrote: > On Fri, Jul 26, 2024 at 8:10 AM Alexander Korotkov > wrote: > > The revised version of 0001 unique checking optimization is attached. > > I'm going to push this to v18 if no objections. > > I have no reason to specifically object to pushing

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Fri, Jul 26, 2024 at 3:42 AM Noah Misch wrote: > On Thu, Jul 25, 2024 at 10:52:13AM +0900, Michael Paquier wrote: > > On Wed, Jul 24, 2024 at 06:00:59AM -0700, Noah Misch wrote: > > > I'm still seeing need for s/int/int64/ at: > > > I am attaching a patch for all these you have spotted,

Re: pg_upgrade failing for 200+ million Large Objects

On Wed, Jul 24, 2024 at 09:17:51AM -0500, Justin Pryzby wrote: > With partitioning, we have a lot of tables, some of them wide (126 > partitioned tables, 8942 childs, total 1019315 columns). On Fri, Jul 26, 2024 at 10:53:30PM +0300, Alexander Korotkov wrote: > It would be nice to identify such

Re: tiny step toward threading: reduce dependence on setlocale()

On Fri, 2024-07-26 at 19:38 +0200, Andreas Karlsson wrote: > Nice refactoring! > > Two small comments about CheckMyDatabase(). > > - Shouldn't we look at the default_locale.ctype_is_c when setting > database_ctype_is_c instead of doing a strcmp()? or maybe we should > even > remove the global

Re: problems with "Shared Memory and Semaphores" section of docs

Committed. -- nathan

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

> test). Which reduces the amount of WAL records from 11MB to 4MB and > would reduce the time to catch up. But I'm not sure how much it would > help. There might be ideas to trigger a two-round index vacuum with > fewer tuples but if the tests are too optimized for the current > Tid

Re: Incremental backup from a streaming replication standby fails

On Fri, Jul 26, 2024 at 4:11 PM Robert Haas wrote: > On Fri, Jul 26, 2024 at 1:09 AM Laurenz Albe wrote: > > > Committed this version to master and v17. > > > > Thanks for taking care of this. > > Sure thing! > > I knew it was going to confuse someone ... I just wasn't sure what to > do about

Re: Assertion failure with summarize_wal enabled during pg_createsubscriber

On Fri, Jul 26, 2024 at 7:02 PM Robert Haas wrote: > On Fri, Jul 26, 2024 at 11:51 AM Nathan Bossart > wrote: > > nitpick: I think this one needs a pgindent. > > Ugh, sorry. I thought of that while I was working on the commit but > then I messed up some other aspect of it and this went out of

Re: pg_upgrade failing for 200+ million Large Objects

Alexander Korotkov writes: > On Wed, Jul 24, 2024 at 5:18 PM Justin Pryzby wrote: >> We'd surely prefer that the transaction size be configurable. > I think we can add an option to pg_upgrade. But I wonder if there is > something else we can do. Yeah, I'm not enamored of adding a command-line

Re: Converting tab-complete.c's else-if chain to a switch

I wrote: > I modified the preprocessor to work like that, and I like the results > better than what I had. I thought this version of the patch would be less subject to merge conflicts than v1, but it didn't take long for somebody to break it. Rebased v3 attached -- no nontrivial changes from v2.

Re: Building with meson on NixOS/nixpkgs

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. -- Tristan Partin Neon (https://neon.tech)

Re: pg_upgrade failing for 200+ million Large Objects

Hi, Justin! Thank you for sharing this. On Wed, Jul 24, 2024 at 5:18 PM Justin Pryzby wrote: > On Mon, Apr 01, 2024 at 03:28:26PM -0400, Tom Lane wrote: > > Nathan Bossart writes: > > > The one design point that worries me a little is the non-configurability > > > of > > > --transaction-size

Re: Inline non-SQL SRFs using SupportRequestSimplify

Heikki Linnakangas writes: > On 28/06/2024 01:01, Paul Jungwirth wrote: >> Another approach I considered is using a separate support request, e.g. >> SupportRequestInlineSRF, and >> just calling it from inline_set_returning_function. I didn't like having two >> support requests that >> did

Re: optimizing pg_upgrade's once-in-each-database steps

On Thu, Jul 25, 2024 at 11:42:55AM +0200, Daniel Gustafsson wrote: >> On 25 Jul 2024, at 04:58, Nathan Bossart wrote: >> Here is just the live_check patch. I rebased it, gave it a commit message, >> and fixed a silly mistake. Barring objections or cfbot indigestion, I plan >> to commit this

Re: tls 1.3: sending multiple tickets

On Fri, Jul 26, 2024 at 10:23 AM Daniel Gustafsson wrote: > We turn off TLS session tickets for two reasons: a) we don't support TLS > session resumption, and some resumption capable client libraries can > experience > connection failures if they try to use tickets received in the setup (Npgsql

Re: [Proposal] Add foreign-server health checks infrastructure

On 2024/07/26 22:44, Fujii Masao wrote: On 2024/07/26 17:07, Hayato Kuroda (Fujitsu) wrote: Dear Fujii-san, Just in case - based on the agreement in [1], I updated patches to keep them consistent. We can use same pictures for further discussions... Thanks for updating the patches! I

Re: Parallel heap vacuum

On Thu, Jul 25, 2024 at 2:58 AM Hayato Kuroda (Fujitsu) wrote: > > Dear Sawada-san, > > > Thank you for the test! > > > > I could reproduce this issue and it's a bug; it skipped even > > non-all-visible pages. I've attached the new version patch. > > > > BTW since we compute the number of

Re: Add ALL_CANDIDATES option to EXPLAIN

On Fri, Jul 26, 2024 at 1:40 PM Tom Lane wrote: > I wonder how far you'd get by just printing the surviving paths > (that is, something like Anthonin's patch, but without lobotomizing > add_path). The survivors would have to dominate the cheapest-total > path along one of the other metrics

Re: xid_wraparound tests intermittent failure.

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, Masahiko Sawada wrote: > > See >

Re: Add ALL_CANDIDATES option to EXPLAIN

Robert Haas writes: > I've thought about trying to figure out some way of identifying and > printing out plans that are "interestingly different" from the chosen > plan, with the costs they would have had, but I haven't been able to > come up with a good algorithm. I wonder how far you'd get by

Re: tiny step toward threading: reduce dependence on setlocale()

Nice refactoring! Two small comments about CheckMyDatabase(). - Shouldn't we look at the default_locale.ctype_is_c when setting database_ctype_is_c instead of doing a strcmp()? or maybe we should even remove the global variable and always look at the default_locale? - I think that the

Re: Add ALL_CANDIDATES option to EXPLAIN

On Fri, Jul 26, 2024 at 12:59 PM Anthonin Bonnefoy wrote: > I have a prototype for an ALL_CANDIDATES option for EXPLAIN. The goal > of this option is to print all plan candidates instead of only the > cheapest plan. It will output the plans from the most expensive at the > top to the cheapest.

Re: Add ALL_CANDIDATES option to EXPLAIN

Anthonin Bonnefoy writes: > I have a prototype for an ALL_CANDIDATES option for EXPLAIN. The goal > of this option is to print all plan candidates instead of only the > cheapest plan. It will output the plans from the most expensive at the > top to the cheapest. This doesn't seem feasible at all

Re: Extension using Meson as build system

On 2024-07-26 Fr 11:06 AM, Peter Eisentraut wrote: On 30.06.24 15:17, Junwang Zhao wrote: Is there any extension that uses meson as build systems? I'm starting a extension project that written in c++, cmake is my initial choice as the build system, but since PostgreSQL has adopted Meson, so

Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

Erik Wienhold writes: > On 2024-07-25 22:29 +0200, Tom Lane wrote: >> This still isn't following our usual message style IMO. Here's a >> proposed v7 that outputs ... > Works for me. Thanks! Pushed, then. regards, tom lane

Re: Detailed release notes

Em sex., 26 de jul. de 2024 às 13:01, Masahiko Sawada escreveu: > > +1. I've been asked a lot of times how to find the associated commit > IDs from release note items. These links would help users know the > details of the changes, and I believe many users would like to do > that. Yes, this

Re: Assertion failure with summarize_wal enabled during pg_createsubscriber

On Fri, Jul 26, 2024 at 11:51 AM Nathan Bossart wrote: > nitpick: I think this one needs a pgindent. Ugh, sorry. I thought of that while I was working on the commit but then I messed up some other aspect of it and this went out of my head. Fixed now, I hope. -- Robert Haas EDB:

Re: Detailed release notes

On Fri, Jul 26, 2024 at 6:56 AM Robert Haas wrote: > > On Fri, Jul 26, 2024 at 9:26 AM Marcos Pegoraro wrote: > > Well, that opened my eyes, now I can see detailed info about every feature > > when it's committed. > > And I'm really convinced that a small link to that commit wouldn't get > >

Re: Assertion failure with summarize_wal enabled during pg_createsubscriber

On Fri, Jul 26, 2024 at 10:09:22AM -0400, Robert Haas wrote: > On Mon, Jul 22, 2024 at 11:02 AM Robert Haas wrote: >> I'm still hoping for some review/feedback/testing of these before I >> commit them, but I also don't want to wait too long. > > Hearing nothing, pushed 0001. nitpick: I think

Re: [PATCH] Add crc32(text) & crc32(bytea)

On Fri, Jul 26, 2024 at 12:01:40PM +0300, Aleksander Alekseev wrote: >> This sounds generally reasonable to me, especially given the apparent >> demand. Should we also introduce crc32c() while we're at it? > > Might be a good idea. However I didn't see a demand for crc32c() SQL > function yet.

Re: Extension using Meson as build system

Hi, Peter On Fri, Jul 26, 2024 at 11:06 PM Peter Eisentraut wrote: > > On 30.06.24 15:17, Junwang Zhao wrote: > > Is there any extension that uses meson as build systems? > > I'm starting a extension project that written in c++, cmake is my > > initial choice as the build system, but since

Re: Extension using Meson as build system

On 30.06.24 15:17, Junwang Zhao wrote: Is there any extension that uses meson as build systems? I'm starting a extension project that written in c++, cmake is my initial choice as the build system, but since PostgreSQL has adopted Meson, so I'm wondering if there is any extension that also uses

Re: add function argument names to regex* functions.

jian he writes: > On Fri, Jul 26, 2024 at 10:17 PM Tom Lane wrote: >> AFAICS, that one is correct, so I left it alone. (I didn't try to >> merge the table's two entries into one like that, though.) > regexp_replace(string, pattern, replacement [, start [, N ]] [, flags ]). > can represent >

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

On Fri, Jul 26, 2024 at 8:10 AM Alexander Korotkov wrote: > The revised version of 0001 unique checking optimization is attached. > I'm going to push this to v18 if no objections. I have no reason to specifically object to pushing this into 18, but I would like to point out that you're posting

Re: Direct SSL connection and ALPN loose ends

On 17/06/2024 21:33, Andres Freund wrote: If provided with the necessary key information, wireshark can decode TLS exchanges when using sslnegotiation=postgres but not with direct. Presumably it needs to be taught postgres' ALPN id or something. I opened

Re: DRAFT: Pass sk_attno to consistent function

> On 26 Jul 2024, at 10:10, Michał Kłeczek wrote: > > > >> On 26 Jul 2024, at 01:28, Matthias van de Meent >> wrote: >> >> All in all, this still seems like a very (very) specific optimization, >> of which I'm not sure that it is generalizable. However, array >> introspection and

Re: add function argument names to regex* functions.

On Fri, Jul 26, 2024 at 10:17 PM Tom Lane wrote: > > > << > > It has the syntax regexp_replace(string, pattern, replacement [, start > > [, N ]] [, flags ]). (Notice that N cannot be specified unless start > > is, but flags can be given in any case.) > > << > > doc, the above part still needs

Re: tls 1.3: sending multiple tickets

> On 26 Jul 2024, at 16:08, Robert Haas wrote: > > On Fri, Jul 26, 2024 at 8:27 AM Daniel Gustafsson wrote: >> Thanks for the report, I'll fix it. Buildfarm animal hamerkop also reminded >> me >> that I had managed to stash the old MSVC buildsystem changes >> (ENOTENOUGHCOFFEE) >> so fixing

Re: pgsql: Add more SQL/JSON constructor functions

On Fri, Jul 26, 2024 at 4:53 PM Amit Langote wrote: > > > Pushed 0003-0005 ahead of 0001-0002. Will try to push them over the > weekend. Rebased for now. { ... /* * For expression nodes that support soft errors. Should be set to NULL * before calling ExecInitExprRec() if the

Re: add function argument names to regex* functions.

jian he writes: > On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote: >> but it is not: we have no function matching that signature. I'm not >> in a hurry to add one, either, for fear of ambiguity against the other >> regexp_replace signature. I think this needs to be broken into two >> syntax

Re: Detailed release notes

Daniel Gustafsson writes: >> On 26 Jul 2024, at 15:00, Marcos Pegoraro wrote: >> But why is that just a hidden comment and not a visible link for us ? > That's likely the wrong level of detail for the overwhelming majority of > release notes readers. I have a feeling this was discussed not too

Re: Assertion failure with summarize_wal enabled during pg_createsubscriber

On Mon, Jul 22, 2024 at 11:02 AM Robert Haas wrote: > I'm still hoping for some review/feedback/testing of these before I > commit them, but I also don't want to wait too long. Hearing nothing, pushed 0001. -- Robert Haas EDB: http://www.enterprisedb.com

Re: tls 1.3: sending multiple tickets

On Fri, Jul 26, 2024 at 8:27 AM Daniel Gustafsson wrote: > Thanks for the report, I'll fix it. Buildfarm animal hamerkop also reminded > me > that I had managed to stash the old MSVC buildsystem changes > (ENOTENOUGHCOFFEE) > so fixing that at the same time. I was just looking at this commit

Re: recoveryCheck/008_fsm_truncation is failing on dodo in v14- (due to slow fsync?)

Hello Robins, 28.06.2024 13:20, Robins Tharakan wrote: The past ~1 week, I tried to space out all other tasks on the machine, so as to ensure that 1-min CPU is mostly <2 (and thus not many things hammering the disk) and with that I see 0 failures these past few days. This isn't conclusive by

Re: Detailed release notes

On Fri, Jul 26, 2024 at 9:26 AM Marcos Pegoraro wrote: > Well, that opened my eyes, now I can see detailed info about every feature > when it's committed. > And I'm really convinced that a small link to that commit wouldn't get dirty > release notes. +1. I think those links would be useful to

Re: add function argument names to regex* functions.

On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote: > > The small issue is that table 9.10 offers this syntax diagram > for regexp_replace: > > regexp_replace ( string text, pattern text, replacement text [, start integer > ] [, flags text ] ) → text > > This implies that it's valid to write > >

Re: [Proposal] Add foreign-server health checks infrastructure

On 2024/07/26 17:07, Hayato Kuroda (Fujitsu) wrote: Dear Fujii-san, Just in case - based on the agreement in [1], I updated patches to keep them consistent. We can use same pictures for further discussions... Thanks for updating the patches! I pushed them. IIUC, the patch which adds

Re: Detailed release notes

On Jul 26, 2024, at 9:26 AM, Marcos Pegoraro wrote:Em sex., 26 de jul. de 2024 às 10:11, Daniel Gustafsson escreveu: That's likely the wrong level of detail for the overwhelming majority of release notes readers.  I have a feeling this was discussed not too long ago but (if so)

Re: Detailed release notes

Em sex., 26 de jul. de 2024 às 10:11, Daniel Gustafsson escreveu: > > That's likely the wrong level of detail for the overwhelming majority of > release notes readers. I have a feeling this was discussed not too long > ago > but (if so) I fail to find that discussion now. Wrong level ? Where

Re: Detailed release notes

> On 26 Jul 2024, at 15:00, Marcos Pegoraro wrote: > But why is that just a hidden comment and not a visible link for us ? That's likely the wrong level of detail for the overwhelming majority of release notes readers. I have a feeling this was discussed not too long ago but (if so) I fail to

Re: Incremental backup from a streaming replication standby fails

On Fri, Jul 26, 2024 at 1:09 AM Laurenz Albe wrote: > > Committed this version to master and v17. > > Thanks for taking care of this. Sure thing! I knew it was going to confuse someone ... I just wasn't sure what to do about it. Now we've at least done something, which is hopefully superior to

Re: Detailed release notes

Em sex., 26 de jul. de 2024 às 09:45, Daniel Gustafsson escreveu: > > There is a way, but it's not exactly visible from reading the release > notes. > Cool, didn't know that. But why is that just a hidden comment and not a visible link for us ? regards Marcos

Re: fairywren timeout failures on the pg_amcheck/005_opclass_damage test

26.07.2024 15:41, Andrew Dunstan wrote: One way to workaround this is to disable debug_parallel_query in the test and another I find possible is to set max_parallel_workers = 0. But wouldn't either of those just be masking the problem? Yes, I'm inclined to consider this behavior a

Re: tls 1.3: sending multiple tickets

On 2024-07-26 15:27, Daniel Gustafsson wrote: On 26 Jul 2024, at 14:03, Marina Polyakova wrote: It looks like the recommended way of using autoheader [1] is now broken. The attached patch fixes the master branch for me. Thanks for the report, I'll fix it. Buildfarm animal hamerkop also

Re: Detailed release notes

> On 26 Jul 2024, at 14:30, Marcos Pegoraro wrote: > > I'm now using version 14 and planning to update to 17 as soon as it comes > available. Then looking carefully to release notes to see exactly what I'll > get when updated I see lots of unexplained features. Just because release > notes

<    1   2   3   4   5   6   7   8   9   10   >