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 ext

Help Needed with Including External SQL Script in Extension Script

Hi PostgreSQL community, 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 extension script using the \i comma

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 public

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 c

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 syntax

pg_attribute.atttypmod for interval type

Hi, I work on a driver for Postgres that utilizes the extended query protocol and have a question about the row description message for interval types. I am trying to use the type modifier value from the message to determine the precision of the interval. This is something I can do for timestamp

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 reduce

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; > > REFR

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 nev

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 qu

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 RANG

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

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 consistenc

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 failures:

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, A

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 MEMORY_CONT

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, ke

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 th

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, switchi

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 cas

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 v

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

Committed. -- nathan

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

On Mon, Jul 22, 2024 at 9:26 PM Masahiko Sawada wrote: > > + CREATE TABLE ${table1}(col1 int) > + WITH (autovacuum_enabled=false, fillfactor=10); > + INSERT INTO $table1 VALUES(7); > + INSERT INTO $table1 SELECT generate_series(1, $nrows) % 3; > + CREATE INDEX on ${table1}(col1); > +

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

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 my

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 i

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 almos

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 with

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 push

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 parallel

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 add_pa

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 j

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 lookup

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

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

Add ALL_CANDIDATES option to EXPLAIN

Hi, 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. Here's an example: explain (all_candidates) select * from pgbenc

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 I'

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 way

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: http://www.ent

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

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 th

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

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 Postgr

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 m

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

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 he

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 https://gitlab.com/wireshark/wireshark/-

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 filtering

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 chan

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 t

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 call

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 diag

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 a

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 a

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 a

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 user_

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 i

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 f

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 n

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 probl

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 remi

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 doe

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

On 2024-07-26 Fr 7:00 AM, Alexander Lakhin wrote: 25.07.2024 15:00, Alexander Lakhin wrote: The other question is: why is 005_opclass_damage taking so much time there? ... $ make -s check -C src/bin/pg_amcheck/ PROVE_TESTS="t/005*" PROVE_FLAGS="--timer" [11:11:53] t/005_opclass_damage.pl

Re: Direct SSL connection and ALPN loose ends

On 24/07/2024 02:37, Michael Paquier wrote: On Tue, Jul 23, 2024 at 08:32:29PM +0300, Heikki Linnakangas wrote: All these new tests are a great asset when refactoring this again. Thanks for doing that. The coverage, especially with v2, is going to be really useful. Yeah, I'm also not too ex

Re: query_id, pg_stat_activity, extended query protocol

On Thu, Jul 18, 2024 at 10:56 AM Michael Paquier wrote: > Please attach things to your emails, if your repository disappears for > a reason or another we would lose knowledge in the archives of the > community lists. Noted and thanks for the reminder, I'm still learning about mailing list etiquet

Detailed release notes

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 does not explain exactly what that change does. And I don't have a wa

Re: tls 1.3: sending multiple tickets

> On 26 Jul 2024, at 14:03, Marina Polyakova wrote: > On 2024-07-26 14:55, Daniel Gustafsson wrote: >> Thanks for review, I've applied this backpatched all the way. > > It looks like the recommended way of using autoheader [1] is now broken. The > attached patch fixes the master branch for me.

Re: Protocol question regarding Portal vs Cursor

On Thu, 25 Jul 2024 at 17:52, Dave Cramer wrote: > > > On Thu, 25 Jul 2024 at 16:19, David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Thursday, July 25, 2024, Dave Cramer wrote: >> >> May not make a difference but… >> >> >>> 2024-07-25 15:55:39 FINEST org.postgresql.core.v3.Query

Re: WIP: parallel GiST index builds

> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote: > > I feel the tricky part about doing that is that we need to make sure the fake > LSNs are all less than the current real LSN when the index build completes > and while that normally should be the case we will have a almost never > exerc

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

On Fri, May 17, 2024 at 1:11 PM Alexander Korotkov wrote: > I think the thread contains enough motivation on why 0002, 0003 and > 0004 are material for post-FF. They are fixes and refactoring for > new-in-v17 feature. I'm going to push them if no objections. > > Regarding 0001, I'd like to ask T

Re: tls 1.3: sending multiple tickets

Hello! On 2024-07-26 14:55, Daniel Gustafsson wrote: Thanks for review, I've applied this backpatched all the way. It looks like the recommended way of using autoheader [1] is now broken. The attached patch fixes the master branch for me. [1] https://www.postgresql.org/message-id/30511.154

Re: tls 1.3: sending multiple tickets

> On 24 Jul 2024, at 07:44, Heikki Linnakangas wrote: > > On 18/06/2024 16:11, Daniel Gustafsson wrote: >>> On 17 Jun 2024, at 19:38, Andres Freund wrote: >>> Seems we ought to use SSL_CTX_set_num_tickets() to prevent issuing the >>> useless >>> tickets? >> Agreed, in 1.1.1 and above as the API

Re: Allow logical failover slots to wait on synchronous replication

On Fri, Jul 26, 2024 at 3:28 PM shveta malik wrote: > > On Tue, Jul 23, 2024 at 10:35 AM Amit Kapila wrote: > > > > On Tue, Jul 9, 2024 at 12:39 AM John H wrote: > > > > > > > Out of curiosity, did you compare with standby_slot_names_from_syncrep > > > > set to off > > > > and standby_slot_name

Re: Conflict detection and logging in logical replication

On Thu, Jul 25, 2024 at 4:12 PM Amit Kapila wrote: > > On Thu, Jul 25, 2024 at 12:04 PM Zhijie Hou (Fujitsu) > wrote: > > > > Here is the V6 patch set which addressed Shveta and Nisha's comments > > in [1][2][3][4]. > > > > Do we need an option detect_conflict for logging conflicts? The > possibl

Re: Built-in CTYPE provider

On Wed, Jul 24, 2024 at 08:19:13AM -0700, Noah Misch wrote: > On Wed, Jul 17, 2024 at 03:03:26PM -0700, Noah Misch wrote: > > vote one way or the other on the question in > > https://postgr.es/m/20240706195129...@rfd.leadboat.com? > > I'll keep the voting open for another 24 hours from now > or 36

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

25.07.2024 15:00, Alexander Lakhin wrote: The other question is: why is 005_opclass_damage taking so much time there? ... $ make -s check -C src/bin/pg_amcheck/ PROVE_TESTS="t/005*" PROVE_FLAGS="--timer" [11:11:53] t/005_opclass_damage.pl .. ok 1370 ms ( 0.00 usr 0.00 sys +  0.10 cusr  0.

Re: Conflict detection and logging in logical replication

On Fri, Jul 26, 2024 at 3:56 PM Amit Kapila wrote: > > On Fri, Jul 26, 2024 at 3:37 PM shveta malik wrote: > > > > On Fri, Jul 26, 2024 at 3:03 PM Nisha Moond > > wrote: > > > > > > On Thu, Jul 25, 2024 at 12:04 PM Zhijie Hou (Fujitsu) > > > wrote: > > > > Here is the V6 patch set which addres

Re: Conflict detection and logging in logical replication

On Fri, Jul 26, 2024 at 3:37 PM shveta malik wrote: > > On Fri, Jul 26, 2024 at 3:03 PM Nisha Moond wrote: > > > > On Thu, Jul 25, 2024 at 12:04 PM Zhijie Hou (Fujitsu) > > wrote: > > > Here is the V6 patch set which addressed Shveta and Nisha's comments > > > in [1][2][3][4]. > > > > Thanks for

Re: Conflict detection and logging in logical replication

On Fri, Jul 26, 2024 at 3:03 PM Nisha Moond wrote: > > On Thu, Jul 25, 2024 at 12:04 PM Zhijie Hou (Fujitsu) > wrote: > > Here is the V6 patch set which addressed Shveta and Nisha's comments > > in [1][2][3][4]. > > Thanks for the patch. > I tested the v6-0001 patch with partition table scenarios

Re: Allow logical failover slots to wait on synchronous replication

On Tue, Jul 23, 2024 at 10:35 AM Amit Kapila wrote: > > On Tue, Jul 9, 2024 at 12:39 AM John H wrote: > > > > > Out of curiosity, did you compare with standby_slot_names_from_syncrep > > > set to off > > > and standby_slot_names not empty? > > > > I didn't think 'standby_slot_names' would impact

Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)

On Wed, Jul 24, 2024 at 3:30 PM Ashutosh Bapat wrote: > Done. Are you suggesting it for aesthetic purposes or there's > something else (read, less defragmentation, performance gain etc.)? I > am curious. I think it's just for readability. > PFA patches: > 0001 - same as previous one > 0002 - add

Re: Conflict detection and logging in logical replication

On Thu, Jul 25, 2024 at 12:04 PM Zhijie Hou (Fujitsu) wrote: > Here is the V6 patch set which addressed Shveta and Nisha's comments > in [1][2][3][4]. Thanks for the patch. I tested the v6-0001 patch with partition table scenarios. Please review the following scenario where Pub updates a tuple, c

Re: Possible null pointer dereference in afterTriggerAddEvent()

25.07.2024 20:07, Alvaro Herrera wrote: Maybe for sanity (and perhaps for Svace compliance) we could do it the other way around, i.e. by testing events->tail for nullness instead of events->head, then add the assertion: if (events->tail == NULL) {

Re: WIP: parallel GiST index builds

On 7/22/24 2:08 PM, Andrey M. Borodin wrote: During inserting tuples we need NSN on page. For NSN we can use just a counter, generated by gistGetFakeLSN() which in turn will call GetFakeLSNForUnloggedRel(). Or any other shared counter. After inserting tuples we call log_newpage_range() to actua

  1   2   >