EphemeralNamedRelation and materialized view

Hi, While looking into the commit b4da732fd64e936970f38c792f8b32c4bdf2bcd5, I noticed that we can create a materialized view using Ephemeral Named Relation in PostgreSQL 16 or earler. postgres=# create table tbl (i int); CREATE TABLE ^ postgr

Re: warning: dereferencing type-punned pointer

> On 24.07.24 20:09, Tom Lane wrote: >> Peter Eisentraut writes: >>> On 24.07.24 16:05, Tom Lane wrote: I'm not very thrilled with these changes. It's not apparent why your compiler is warning about these usages of IsA and not any other ones, >>> I think one difference is that norm

Re: warning: dereferencing type-punned pointer

Sorry, I forgot to attach the file... > I don't agree. I think the compiler just dislike that nodeTag macro's > argument is a pointer created by '&' operator in this case: > > #define nodeTag(nodeptr) (((const Node*)(nodeptr))->type) > > If we just give a pointer variable either it's type is No

Re: Separate HEAP WAL replay logic into its own file

> On Jul 23, 2024, at 09:54, Sutou Kouhei wrote: > > > Here are my comments for your patch: > > 1. Could you create your patch by "git format-patch -vN master" > or something? If you create your patch by "git format-patch", > we can apply your patch by "git am XXX.patch". > Thanks for your

Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan

On Thu, Jul 25, 2024 at 12:07 AM Tom Lane wrote: > I took a brief look at this. I think the basic idea is sound, > but I have a couple of nits: Thank you for reviewing this patch! > * It's not entirely obvious that the checks preceding these additions > are sufficient to ensure that the clauses

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

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... IIUC, the patch which adds user_name attribute to get_connection() can be discussed in later stage, is it right? [1]: https://www.postgre

Re: DRAFT: Pass sk_attno to consistent function

> 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 for SAOP equality checks feel like a > relatively easy (?) push-d

Re: Restart pg_usleep when interrupted

Hi, On Thu, Jul 25, 2024 at 05:27:15PM -0500, Sami Imseih wrote: > I am attaching v3 of the patch which addresses the comments made > earlier by Bertrand about the comment in the patch [1]. Thanks! Looking at it: 1 === + struct instr_time start_time; I think we can get rid of the "struc

Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

On 2024-Jul-26, Junwang Zhao wrote: > There is a bug report[0] Tender comments might be the same > issue as this one, but I tried Alvaro's and mine patch, neither > could solve that problem, I did not tried Tender's earlier patch > thought. I post the test script below in case you are interested.

Re: pgsql: Add more SQL/JSON constructor functions

On Fri, Jul 26, 2024 at 11:12 AM Amit Langote wrote: > On Thu, Jul 25, 2024 at 11:16 PM Amit Langote wrote: > > On Wed, Jul 24, 2024 at 3:25 PM jian he wrote: > > > 2. domain over jsonb should fail just like domain over other types? > > > RETURNING djs keep quotes DEFAULT '"11"' ON empty > > > s

Re: Remove duplicate table scan in logical apply worker and code refactoring

On Thu, Jul 25, 2024 at 5:56 PM Kirill Reshke wrote: > > +/* > > + * If the tuple to be modified could not be found, a log message is > > emitted. > > + */ > > +static void > > +report_tuple_not_found(CmdType cmd, Relation targetrel, bool is_partition) > > +{ > > + Assert(cmd == CMD_UPDATE || cm

Re: Make COPY format extendable: Extract COPY TO format implementations

> On Jul 25, 2024, at 12:51, Sutou Kouhei wrote: > > Hi, > > THREAD SUMMARY: Very nice summary. > > Implementation: > > The v18 patch set is the latest patch set. [6] > It includes the following patches: > > 0001: This adds a basic feature (Copy{From,To}Routine) > (This isn't enough

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

Hi, > 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. Also I'm not sure whether the best interface for it would be crc32c() or c

Re: consider -Wmissing-variable-declarations

I have committed all of the fixes that I had previously posted, but before actually activating the warning option, I found another small hiccup with the Bison files. Before Bison 3.4, the generated parser implementation files run afoul of -Wmissing-variable-declarations (in spite of commit ab6

Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

Junwang Zhao 于2024年7月26日周五 14:57写道： > > There is a bug report[0] Tender comments might be the same > issue as this one, but I tried Alvaro's and mine patch, neither > could solve that problem, I did not tried Tender's earlier patch > thought. I post the test script below in case you are intereste

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

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

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

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

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

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

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

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

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: 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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: problems with "Shared Memory and Semaphores" section of docs

Committed. -- nathan

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

  1   2   >