Re: fix tablespace handling in pg_combinebackup

I don't know how to fix 82023d47^ on Windows[1][2], but in case it's useful, here's a small clue. I see that Perl's readlink() does in fact know how to read "junction points" on Windows[3], so if that was the only problem it might have been very close to working. One difference is that our own

Re: subscription/026_stats test is intermittently slow?

Hello Michael and Robert, 20.04.2024 05:57, Michael Paquier wrote: On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote: It looks to me like in the first run it took 3 minutes for the replay_lsn to catch up to the desired value, and in the second run, two seconds. I think I have seen

Re: UniqueKey v2

Hello Antonin, > zhihuifan1...@163.com wrote: > >> Here is the v3, ... > > I'm trying to enhance the join removal functionality (will post my patch in a > separate thread soon) and I consider your patch very helpful in this > area. Thanks for these words. The point 2) and 3) is pretty

Re: tablecmds.c/MergeAttributes() cleanup

On Sat, Apr 20, 2024 at 9:30 AM Alexander Lakhin wrote: > Hello, > > 30.01.2024 09:22, Ashutosh Bapat wrote: > > > >> Please look at the segmentation fault triggered by the following query > since > >> 4d969b2f8: > >> CREATE TABLE t1(a text COMPRESSION pglz); > >> CREATE TABLE t2(a text); > >>

Re: Typos in the code and README

On Fri, 19 Apr 2024 at 20:13, Daniel Gustafsson wrote: > Thanks, I incorporated these into 0001 before pushing. All the commits in > this > patchset are now applied. Here are a few more to see if it motivates anyone else to do a more thorough search for another batch. Fixes duplicate words

Re: tablecmds.c/MergeAttributes() cleanup

Hello, 30.01.2024 09:22, Ashutosh Bapat wrote: Please look at the segmentation fault triggered by the following query since 4d969b2f8: CREATE TABLE t1(a text COMPRESSION pglz); CREATE TABLE t2(a text); CREATE TABLE t3() INHERITS(t1, t2); NOTICE: merging multiple inherited definitions of

Re: Stability of queryid in minor versions

On Sat, Apr 20, 2024 at 01:56:48PM +1200, David Rowley wrote: > Thanks for the review. I've now pushed this, backpatching to 12. You've split that into two separate paragraphs with 2d3389c28c5c. Thanks for the commit. -- Michael signature.asc Description: PGP signature

Re: subscription/026_stats test is intermittently slow?

On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote: > It looks to me like in the first run it took 3 minutes for the > replay_lsn to catch up to the desired value, and in the second run, > two seconds. I think I have seen previous instances where something > similar happened, although in

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On Fri, Apr 19, 2024 at 10:41:30AM +0900, Michael Paquier wrote: > This comes from the contents of the dump for > regress_pg_dump_table_am_2, that uses heap as table AM. A SET is > issued for it before dumping regress_pg_dump_table_am_parent and its > partitions. One trick that I can think of to

Re: Remove deprecated header file resowner_private.h.

On Sat, Apr 20, 2024 at 10:07:45AM +0800, Xing Guo wrote: > I noticed that the header file resowner_private.h is deprecated and no > longer useful after commit b8bff07[^1]. We should remove it. Nice catch, looks like a `git rm` has been slippery here . It is indeed confusing to keep it around

Remove deprecated header file resowner_private.h.

Hi hackers, I noticed that the header file resowner_private.h is deprecated and no longer useful after commit b8bff07[^1]. We should remove it. [^1]: https://github.com/postgres/postgres/commit/b8bff07daa85c837a2747b4d35cd5a27e73fb7b2 Best Regards, Xing From

Re: Stability of queryid in minor versions

On Tue, 16 Apr 2024 at 15:16, Michael Paquier wrote: > > On Tue, Apr 16, 2024 at 02:04:22PM +1200, David Rowley wrote: > > It makes sense to talk about the hashing variations closer to the > > object identifier part. > > Mostly what I had in mind. A separate for the new part you are > adding at

Re: brininsert optimization opportunity

On Fri, Apr 19, 2024 at 04:14:00PM +0200, Tomas Vondra wrote: > FWIW I've pushed both patches, which resolves the open item, so I've > moved it to the "resolved" part on wiki. Thanks, Tomas! -- Michael signature.asc Description: PGP signature

Re: Use XLOG_CONTROL_FILE macro everywhere?

On Fri, Apr 19, 2024 at 10:12:14AM +0200, Daniel Gustafsson wrote: > Off the cuff that seems to make sense, it does make it easier to grep for uses > of the control file. +1 for switching to the macro where we can. Still, I don't see a point in rushing and would just switch that once v18 opens

Re: Support a wildcard in backtrace_functions

On Fri, Apr 19, 2024 at 04:17:18PM -0400, Robert Haas wrote: > On Fri, Apr 19, 2024 at 3:24 PM Tom Lane wrote: >> I can't say that I care for "backtrace_on_internal_error". >> Re-reading that thread, I see I argued for having *no* GUC and >> just enabling that behavior all the time. I lost that

Re: Direct SSL connection with ALPN and HBA rules

On 19/04/2024 19:48, Jacob Champion wrote: On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote: With direct SSL negotiation, we always require ALPN. (As an aside: I haven't gotten to test the version of the patch that made it into 17 yet, but from a quick glance it looks like we're

Re: fix tablespace handling in pg_combinebackup

On Fri, Apr 19, 2024 at 4:18 PM Tom Lane wrote: > Robert Haas writes: > > On Fri, Apr 19, 2024 at 3:31 PM Tom Lane wrote: > >> That would be a reasonable answer if we deem the problem to be > >> just "the buildfarm is unhappy". What I'm wondering about is > >> whether the feature will be

Re: allow changing autovacuum_max_workers without restarting

On Fri, Apr 19, 2024 at 02:42:13PM -0400, Robert Haas wrote: > I think this could help a bunch of users, but I'd still like to > complain, not so much with the desire to kill this patch as with the > desire to broaden the conversation. I think I subconsciously hoped this would spark a bigger

Re: fix tablespace handling in pg_combinebackup

Robert Haas writes: > On Fri, Apr 19, 2024 at 3:31 PM Tom Lane wrote: >> That would be a reasonable answer if we deem the problem to be >> just "the buildfarm is unhappy". What I'm wondering about is >> whether the feature will be useful to end users with this >> pathname length restriction. >

Re: Support a wildcard in backtrace_functions

On Fri, Apr 19, 2024 at 3:24 PM Tom Lane wrote: > I can't say that I care for "backtrace_on_internal_error". > Re-reading that thread, I see I argued for having *no* GUC and > just enabling that behavior all the time. I lost that fight, > but it should have been clear that a GUC of this exact

Re: postgres_fdw fails because GMT != UTC

Etsuro Fujita writes: > On Thu, Apr 4, 2024 at 3:49 PM Laurenz Albe wrote: >> On Thu, 2024-04-04 at 02:19 -0400, Tom Lane wrote: >>> I am not quite clear on how broken an installation needs to be to >>> reject "UTC" as a time zone setting, except that the breakage cannot >>> be subtle. However,

Re: fix tablespace handling in pg_combinebackup

On Fri, Apr 19, 2024 at 3:31 PM Tom Lane wrote: > That would be a reasonable answer if we deem the problem to be > just "the buildfarm is unhappy". What I'm wondering about is > whether the feature will be useful to end users with this > pathname length restriction. Possibly you're getting a

Re: fix tablespace handling in pg_combinebackup

Robert Haas writes: > On Fri, Apr 19, 2024 at 2:44 PM Tom Lane wrote: >> This patch failed to survive contact with the buildfarm. It looks >> like the animals that are unhappy are choking like this: >> pg_basebackup: error: backup failed: ERROR: symbolic link target too long >> for tar

Re: Support a wildcard in backtrace_functions

Robert Haas writes: > On Fri, Apr 19, 2024 at 2:08 PM Tom Lane wrote: >> I've not been following this thread, so I don't have an opinion >> about what the design ought to be. But if we still aren't settled >> on it by now, I think the prudent thing is to revert the feature >> out of v17

Re: fix tablespace handling in pg_combinebackup

On Fri, Apr 19, 2024 at 2:44 PM Tom Lane wrote: > Robert Haas writes: > > On Thu, Apr 18, 2024 at 1:45 PM Andres Freund wrote: > >> Just to be clear: I don't want the above to block merging your test. If you > >> think you want to do it the way you did, please do. > > > I think I will go ahead

Re: Support a wildcard in backtrace_functions

On Fri, Apr 19, 2024 at 2:08 PM Tom Lane wrote: > Robert Haas writes: > > There are some things that are pretty hard to change once we've > > released them. For example, if we had a function or operator and > > somebody embeds it in a view definition, removing or renaming it > > prevents people

Re: fix tablespace handling in pg_combinebackup

Robert Haas writes: > On Thu, Apr 18, 2024 at 1:45 PM Andres Freund wrote: >> Just to be clear: I don't want the above to block merging your test. If you >> think you want to do it the way you did, please do. > I think I will go ahead and do that soon, then. This patch failed to survive

Re: allow changing autovacuum_max_workers without restarting

On Fri, Apr 19, 2024 at 11:43 AM Nathan Bossart wrote: > Removed in v2. I also noticed that I forgot to update the part about when > autovacuum_max_workers can be changed. *facepalm* I think this could help a bunch of users, but I'd still like to complain, not so much with the desire to kill

Re: Support a wildcard in backtrace_functions

Robert Haas writes: > There are some things that are pretty hard to change once we've > released them. For example, if we had a function or operator and > somebody embeds it in a view definition, removing or renaming it > prevents people from upgrading. But GUCs are not as bad. Really? Are we

Re: WIP Incremental JSON Parser

On Fri, Apr 19, 2024 at 1:35 AM Michael Paquier wrote: > Are you sure that relying on Temp::File is a good thing overall? The > current temporary file knowledge is encapsulated within Utils.pm, with > files removed or kept depending on PG_TEST_NOCLEAN. So it would be > just more consistent to

subscription/026_stats test is intermittently slow?

I just did a run of the regression test where this test was the last one to finish by quite a lot. Key log entries: [13:35:48.583](0.039s) # initializing database system by copying initdb template ... [13:35:52.397](0.108s) ok 5 - Check reset timestamp for 'test_tab1_sub' is newer after second

Re: Support event trigger for logoff

Japin Li writes: > I see [1] has already implemented on login event trigger, why not implement > the logoff event trigger? What happens if the session crashes, or otherwise fails unexpectedly? > Here is a problem with the regression test when using \c to create a new > session, because it might

Re: Support a wildcard in backtrace_functions

On Fri, Apr 19, 2024 at 7:31 AM Jelte Fennema-Nio wrote: > While there maybe isn't consensus on what a new design exactly looks > like, I do feel like there's consensus on this thread that the > backtrace_on_internal_error GUC is almost certainly not the design > that we want. I guess a more

Re: Direct SSL connection with ALPN and HBA rules

On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote: > On 19/04/2024 08:06, Michael Paquier wrote: > > Since 91044ae4baea (require ALPN for direct SSL connections) and > > d39a49c1e459 (direct hanshake), direct SSL connections are supported > > (yeah!), still the thread where this has been

Re: Support a wildcard in backtrace_functions

On Thu, Apr 18, 2024 at 3:02 AM Michael Paquier wrote: > As this is an open item, let's move on here. > > Attached is a proposal of patch for this open item, switching > backtrace_on_internal_error to backtrace_mode with two values: > - "none", to log no backtraces. > - "internal", to log

Re: pg_combinebackup does not detect missing files

On Thu, Apr 18, 2024 at 7:36 PM David Steele wrote: > Sure -- pg_combinebackup would only need to verify the data that it > uses. I'm not suggesting that it should do an exhaustive verify of every > single backup in the chain. Though I can see how it sounded that way > since with pg_verifybackup

Support event trigger for logoff

Hi, hackers I see [1] has already implemented on login event trigger, why not implement the logoff event trigger? My friend Song Jinzhou and I try to implement the logoff event trigger, so attach it. Here is a problem with the regression test when using \c to create a new session, because it

Re: allow changing autovacuum_max_workers without restarting

On Thu, Apr 18, 2024 at 05:05:03AM +, Imseih (AWS), Sami wrote: > I looked at the patch set. With the help of DEBUG2 output, I tested to ensure > that the the autovacuum_cost_limit balance adjusts correctly when the > autovacuum_max_workers value increases/decreases. I did not think the >

Re: ECPG cleanup and fix for clang compile-time problem

One other bit of randomness that I noticed: ecpg's parse.pl has this undocumented bit of logic: if ($a eq 'IDENT' && $prior eq '%nonassoc') { # add more tokens to the list $str = $str . "\n%nonassoc CSTRING";

Re: Idea Feedback: psql \h misses -> Offers Links?

On Wed, Apr 17, 2024, at 2:47 PM, Kirk Wolak wrote: > I often use the ctrl-click on the link after getting help in psql. A great > feature. > > Challenge, when there is no help, you don't get any link. > > My thought process is to add a default response that would take them to >

Re: brininsert optimization opportunity

On 4/19/24 00:13, Tomas Vondra wrote: > ... > > It's a bit too late for me to push this now, I'll do so early tomorrow. > FWIW I've pushed both patches, which resolves the open item, so I've moved it to the "resolved" part on wiki. thanks -- Tomas Vondra EnterpriseDB:

Re: Possible to exclude a database from loading a shared_preload_libraries module?

Rajan Pandey writes: > Hi, I have a use case where I want a particular database to not load a few > modules in shared_preload_libraries. > I was wondering if there's any way to tweak the codebase to achieve this. No. It's not even theoretically possible, because the whole point of

Re: Direct SSL connection with ALPN and HBA rules

On 19/04/2024 08:06, Michael Paquier wrote: Hi all, (Heikki in CC.) (Adding Jacob) Since 91044ae4baea (require ALPN for direct SSL connections) and d39a49c1e459 (direct hanshake), direct SSL connections are supported (yeah!), still the thread where this has been discussed does not cover the

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

> On 19 Apr 2024, at 15:13, David Benjamin wrote: > > Circling back here, anything else needed from my end on this patch? Patience mostly, v17 very recently entered feature freeze so a lof of the developers are busy finding and fixing bugs to stabilize the release. When the window for new

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

Circling back here, anything else needed from my end on this patch? On Wed, Feb 21, 2024, 17:04 David Benjamin wrote: > Thanks for the very thorough comments! I've attached a new version of the > patch. > > On Thu, Feb 15, 2024 at 4:17 PM Andres Freund wrote: > >> Hi, >> >> On 2024-02-11

Re: Okay to remove mention of mystery @ and ~ operators?

> On 19 Apr 2024, at 13:49, Daniel Gustafsson wrote: >> On 19 Apr 2024, at 12:31, Aleksander Alekseev >> wrote: >> Here is the patch. > > Nice catch, and thanks for the patch. I'll apply it with a backpatch to when > they were removed. Done, thanks for the report and the patch! -- Daniel

Possible to exclude a database from loading a shared_preload_libraries module?

Hi, I have a use case where I want a particular database to not load a few modules in shared_preload_libraries. I was wondering if there's any way to tweak the codebase to achieve this. Otherwise, can I block the modules' hooks/bgw from performing actions on my particular database? -- Regards

Re: Okay to remove mention of mystery @ and ~ operators?

> On 19 Apr 2024, at 12:31, Aleksander Alekseev > wrote: > > Hi, > >>> This page says that the `@` and `~` operators on various types can be >>> accelerated by a GiST index. >>> >>> https://www.postgresql.org/docs/current/gist-builtin-opclasses.html >>> >>> These operators have been listed

Re: documentation structure

On Wed, Apr 17, 2024 at 7:07 PM Dagfinn Ilmari Mannsåker wrote: > > > > It'd also be quite useful if clients could render more of the documentation > > for functions. People are used to language servers providing full > > documentation for functions etc... > > A more user-friendly version of \df+

Re: UniqueKey v2

zhihuifan1...@163.com wrote: > Here is the v3, ... I'm trying to enhance the join removal functionality (will post my patch in a separate thread soon) and I consider your patch very helpful in this area. Following is my review. Attached are also some fixes and one enhancement: propagation of

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Thu, Apr 11, 2024 at 10:20:53PM -0400, Robert Haas wrote: > On Thu, Apr 11, 2024 at 9:54 PM Alexander Korotkov > wrote: > > I think we shouldn't unconditionally copy schema name and > > relpersistence from the parent table. Instead we should throw the > > error on a mismatch like CREATE

Re: Support a wildcard in backtrace_functions

On Fri, 19 Apr 2024 at 10:58, Peter Eisentraut wrote: > This presupposes that there is consensus about how the future > functionality should look like. This topic has gone through half a > dozen designs over a few months, and I think it would be premature to > randomly freeze that discussion now

Re: AIX support

For any complier/hardware related issue we should able to provide support. We are in the process of identifying the AIX systems that can be added to the CI/buildfarm environment. Regards, Sriram.

Re: POC: GROUP BY optimization

On Thu, Apr 18, 2024 at 6:58 PM Alexander Korotkov wrote: > > Thank you for the fixes you've proposed. I didn't look much into > details yet, but I think the main concern Tom expressed in [1] is > whether the feature is reasonable at all. I think at this stage the > most important thing is to

Re: Okay to remove mention of mystery @ and ~ operators?

Hi, > > This page says that the `@` and `~` operators on various types can be > > accelerated by a GiST index. > > > > https://www.postgresql.org/docs/current/gist-builtin-opclasses.html > > > > These operators have been listed in the file since it was created in 2014, > > but if they exist

Re: Okay to remove mention of mystery @ and ~ operators?

Hi, > This page says that the `@` and `~` operators on various types can be > accelerated by a GiST index. > > https://www.postgresql.org/docs/current/gist-builtin-opclasses.html > > These operators have been listed in the file since it was created in 2014, > but if they exist then I don't know

Re: Disallow changing slot's failover option in transaction block

On Fri, Apr 19, 2024 at 6:09 AM Zhijie Hou (Fujitsu) wrote: > > Here is V2 patch which includes the changes for CREATE SUBSCRIPTION as > suggested. Since we don't connect pub to alter slot when (create_slot=false) > anymore, the restriction that disallows failover=true when connect=false is >

Okay to remove mention of mystery @ and ~ operators?

Hello This page says that the `@` and `~` operators on various types can be accelerated by a GiST index. https://www.postgresql.org/docs/current/gist-builtin-opclasses.html These operators have been listed in the file since it was created in 2014, but if they exist then I don't know how to use

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

Hi, > > Fair point. PFA the alternative version of the patch. > > > > Thanks. Committed. Thanks. I see a few pieces of code that use special FOO_NUMBER enum values instead of a macro. Should we refactor these pieces accordingly? PFA another patch. -- Best regards, Aleksander Alekseev

Re: Trigger violates foreign key constraint

Hi, > Perhaps we should leave the system triggers out of the discussion > entirely? More or less like: > > If a foreign key constraint specifies referential actions (that > is, cascading updates or deletes), those actions are performed via > ordinary SQL update or delete commands on

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

On Thu, 18 Apr 2024 at 13:00, Aleksander Alekseev wrote: > > Fair point. PFA the alternative version of the patch. > Thanks. Committed. Regards, Dean

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

18.04.2024 20:49, Alvaro Herrera wrote: On 2024-Apr-18, Alexander Lakhin wrote: I think the feature implementation should also provide tab completion for SPLIT/MERGE. I don't think that we should be imposing on feature authors or committers the task of filling in tab-completion for whatever

Re: Support a wildcard in backtrace_functions

On 18.04.24 11:54, Jelte Fennema-Nio wrote: On Thu, 18 Apr 2024 at 10:50, Peter Eisentraut wrote: Why exactly is this an open item? Is there anything wrong with the existing feature? The name of the GUC backtrace_on_internal_error is so specific that it's impossible to extend our backtrace

Re: Disallow changing slot's failover option in transaction block

Hi, On Fri, Apr 19, 2024 at 12:39:40AM +, Zhijie Hou (Fujitsu) wrote: > Here is V2 patch which includes the changes for CREATE SUBSCRIPTION as > suggested. Since we don't connect pub to alter slot when (create_slot=false) > anymore, the restriction that disallows failover=true when

Re: Idea Feedback: psql \h misses -> Offers Links?

On 18.04.24 23:29, Kirk Wolak wrote: On Thu, Apr 18, 2024 at 2:37 PM Peter Eisentraut > wrote: On 17.04.24 19:47, Kirk Wolak wrote: > *Example:* > \h current_setting > No help available for "current_setting". > Try \h with no arguments to see

Re: Cannot find a working 64-bit integer type on Illumos

On 18.04.24 02:31, Thomas Munro wrote: For limits, why do we have this: - * stdint.h limits aren't guaranteed to have compatible types with our fixed - * width types. So just define our own. ? I mean, how could they not have compatible types? The commit for this was 62e2a8dc2c7 and the

Re: promotion related handling in pg_sync_replication_slots()

On Fri, Apr 19, 2024 at 11:37 AM shveta malik wrote: > > On Fri, Apr 19, 2024 at 10:53 AM Bertrand Drouvot > wrote: > > > > Hi, > > > > On Thu, Apr 18, 2024 at 05:36:05PM +0530, shveta malik wrote: > > > Please find v8 attached. Changes are: > > > > Thanks! > > > > A few comments: > > Thanks for

Re: Typos in the code and README

> On 16 Apr 2024, at 15:37, Nazir Bilal Yavuz wrote: > I realized two small typos: 'sgmr' -> 'smgr'. You may want to include > them in 0001. Thanks, I incorporated these into 0001 before pushing. All the commits in this patchset are now applied. -- Daniel Gustafsson

Re: Use XLOG_CONTROL_FILE macro everywhere?

> On 19 Apr 2024, at 05:50, Anton A. Melnikov wrote: > May be better use this macro everywhere in C code? Off the cuff that seems to make sense, it does make it easier to grep for uses of the control file. -- Daniel Gustafsson

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

On 19.04.24 07:37, Michael Paquier wrote: On Thu, Apr 18, 2024 at 12:53:43PM +0200, Peter Eisentraut wrote: If everything is addressed, I agree that 0001, 0003, and 0004 can go into PG17, the rest later. About the PG17 bits, would you agree about a backpatch? Or perhaps you disagree? I

Re: Show WAL write and fsync stats in pg_stat_io

Hi, On Mon, 19 Feb 2024 at 10:28, Nazir Bilal Yavuz wrote: > > Hi, > > On Thu, 18 Jan 2024 at 04:22, Michael Paquier wrote: > > > > On Wed, Jan 17, 2024 at 03:20:39PM +0300, Nazir Bilal Yavuz wrote: > > > I agree with your points. While the other I/O related work is > > > happening we can

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

> On 19 Apr 2024, at 07:37, Michael Paquier wrote: > > On Thu, Apr 18, 2024 at 12:53:43PM +0200, Peter Eisentraut wrote: >> If everything is addressed, I agree that 0001, 0003, and 0004 can go into >> PG17, the rest later. > > About the PG17 bits, would you agree about a backpatch? Or perhaps

Re: Can't find not null constraint, but \d+ shows that

Alvaro Herrera 于2024年4月19日周五 02:49写道： > On 2024-Apr-13, jian he wrote: > > > I wonder is there any incompatibility issue, or do we need to say > something > > about the new behavior when dropping a key column? > > Umm, yeah, maybe we should document it in ALTER TABLE DROP PRIMARY KEY > and in

Re: promotion related handling in pg_sync_replication_slots()

On Fri, Apr 19, 2024 at 10:53 AM Bertrand Drouvot wrote: > > Hi, > > On Thu, Apr 18, 2024 at 05:36:05PM +0530, shveta malik wrote: > > Please find v8 attached. Changes are: > > Thanks! > > A few comments: Thanks for reviewing. > 1 === > > @@ -1440,7 +1461,7 @@ ReplSlotSyncWorkerMain(char