Re: query_id, pg_stat_activity, extended query protocol

On 5/1/24 10:07, Imseih (AWS), Sami wrote: Here is a new rev of the patch which deals with the scenario mentioned by Andrei [1] in which the queryId may change due to a cached query invalidation. [1] https://www.postgresql.org/message-id/724348C9-8023-41BC-895E-80634E79A538%40amazon.com I

Re: cannot abort transaction 2737414167, it was already committed

On Thu, Dec 28, 2023 at 11:42 AM Tom Lane wrote: > Thomas Munro writes: > > In CommitTransaction() there is a stretch of code beginning s->state = > > TRANS_COMMIT and ending s->state = TRANS_DEFAULT, from which we call > > out to various subsystems' AtEOXact_XXX() functions. There is no way >

Re: First draft of PG 17 release notes

Hi, On Thu, May 9, 2024 at 1:03 PM Bruce Momjian wrote: > > I have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html Thank you for working on that! I'd like to mention some of my works. I think we

Re: First draft of PG 17 release notes

Hi, On Thu, May 09, 2024 at 12:03:50AM -0400, Bruce Momjian wrote: > I have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html Thanks for working on that! > I welcome feedback. > Add system view

Re: First draft of PG 17 release notes

On Thu, 9 May 2024 at 16:47, Muhammad Ikram wrote: > A minor formatting issue in the start below. Bullet is not required here. This is a placeholder for the highlight features of v17 will go. Bruce tends not to decide what those are all by himself. David

Re: Weird test mixup

On Wed, May 08, 2024 at 08:15:53PM -0700, Noah Misch wrote: > Yes, that would be a loss for test readability. Also, I wouldn't be surprised > if some test will want to attach POINT-B while POINT-A is in injection_wait(). Not impossible, still annoying with more complex scenarios. > Various

Re: First draft of PG 17 release notes

Hi Bruce, A minor formatting issue in the start below. Bullet is not required here. E.1.1. Overview PostgreSQL 17 contains many new features and enhancements, including: - The above items and other new features of

Re: First draft of PG 17 release notes

On Thu, 9 May 2024 at 16:04, Bruce Momjian wrote: > I welcome feedback. For some reason it was an easier job than usual. Thanks for working on that. > +2023-11-02 [cac169d68] Increase DEFAULT_FDW_TUPLE_COST from 0.01 to 0.2 > +Double the default foreign data wrapper tuple cost (David Rowley,

Re: [PATCH] json_lex_string: don't overread on bad UTF8

On Wed, May 08, 2024 at 07:01:08AM -0700, Jacob Champion wrote: > On Tue, May 7, 2024 at 10:31 PM Michael Paquier wrote: >> But looking closer, I can see that in the JSON_INVALID_TOKEN case, >> when !tok_done, we set token_terminator to point to the end of the >> token, and that would include an

Re: SQL:2011 application time

Here are a couple new patches, rebased to e305f715, addressing Peter's feedback. I'm still working on integrating jian he's suggestions for the last patch, so I've omitted that one here. On 5/8/24 06:51, Peter Eisentraut wrote: About

First draft of PG 17 release notes

I have committed the first draft of the PG 17 release notes; you can see the results here: https://momjian.us/pgsql_docs/release-17.html It will be improved until the final release. The item count is 188, which is similar to recent releases: release-10: 189

Non-systematic handling of EINTR/EAGAIN/EWOULDBLOCK

Hello hackers, Looking at a recent failure on the buildfarm: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=morepork=2024-04-30%2020%3A48%3A34 # poll_query_until timed out executing this query: # SELECT archived_count FROM pg_stat_archiver # expecting this output: # 1 # last actual

Re: PERIOD foreign key feature

On 5/8/24 07:44, Bruce Momjian wrote: On Wed, May 8, 2024 at 02:29:34PM +0200, Peter Eisentraut wrote: Yes, David is correct here on all points. I like his suggestion to clarify the language here also. If you need a patch from me let me know, but I assume it's something a committer can just

Re: Expand applicability of aggregate's sortop optimization

On Thu, 9 May 2024 at 13:08, David Rowley wrote: > One additional thought is that the above method would also help > eliminate redundant sorting in queries with a GROUP BY clause. > Whereas, the can_minmax_aggs optimisation is not applied in that case. Another argument for using this method is

Re: Support tid range scan in parallel?

On Thu, 9 May 2024 at 10:23, Cary Huang wrote: > The v3 patch is attached. I've not looked at the patch, but please add it to the July CF. I'll try and look in more detail then. David

Re: Weird test mixup

On Thu, May 09, 2024 at 09:37:54AM +0900, Michael Paquier wrote: > On Tue, May 07, 2024 at 11:53:10AM -0700, Noah Misch wrote: > > The problem I'm trying to tackle in this thread is to make > > src/test/modules/gin installcheck-safe. $SUBJECT's commit 5105c90 started > > that work, having seen

Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS make server crash, regress test fail.

On Thu, May 9, 2024 at 6:40 AM Tom Lane wrote: > David Rowley writes: > > I'm fine with this one as it's the same as what I already mentioned > > earlier. I had imagined doing bms_del_member(bms_copy ... but maybe > > the compiler is able to optimise away the additional store. Likely, it > >

Re: Slow catchup of 2PC (twophase) transactions on replica in LR

Hi, Here are some review comments for v7-0002 == Commit message 1. IIUC there is quite a lot of subtlety and details about why the slot option needs to be changed only when altering "true" to "false", but not when altering "false" to "true". It also should explain why

Re: Slow catchup of 2PC (twophase) transactions on replica in LR

Hi Kuroda-san, Thanks for addressing most of my v6-0001 review comments. Below are some minor follow-up comments for v7-0001. == src/backend/access/transam/twophase.c 1. IsTwoPhaseTransactionGidForSubid +/* + * IsTwoPhaseTransactionGidForSubid + * Check whether the given GID is formed by

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

On Fri, Apr 19, 2024 at 10:14 AM Euler Taveira wrote: > On Wed, Apr 17, 2024, at 2:47 PM, Kirk Wolak wrote: > > ... > > This is Question 1: Do others see the potential value here? > > > Yes. However, I expect an exact and direct answer. There will be cases > that the > first result is not the

Re: Expand applicability of aggregate's sortop optimization

On Thu, 9 May 2024 at 12:26, David Rowley wrote: > I wonder if we should also consider as an alternative to this to just > have an aggregate support function, similar to > SupportRequestOptimizeWindowClause that just nullifies the aggorder / > aggdistinct fields for Min/Max aggregates on types

Re: Weird test mixup

On Tue, May 07, 2024 at 11:53:10AM -0700, Noah Misch wrote: > On Tue, May 07, 2024 at 10:17:49AM +0900, Michael Paquier wrote: >> Always resetting >> condition->name when detaching a point is a simpler flow and saner >> IMO. >> >> Overall, this switches from one detach behavior to a different

Re: Expand applicability of aggregate's sortop optimization

On Wed, 8 May 2024 at 22:13, Matthias van de Meent wrote: > As you may know, aggregates like SELECT MIN(unique1) FROM tenk1; are > rewritten as SELECT unique1 FROM tenk1 ORDER BY unique1 USING < LIMIT > 1; by using the optional sortop field in the aggregator. > However, this optimization is

Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall

On Wed, May 08, 2024 at 02:49:58PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Thanks for looking. I noticed that the version check is unnecessary since >> we always use the new binary's pg_dump[all], so I removed that in v2. > > +1 +1. Could there be an argument in favor of a

Re: ALTER EXTENSION SET SCHEMA versus dependent types

On Wed, May 08, 2024 at 07:57:55PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Agreed. Another option could be to just annotate the arguments with the >> parameter names. > > At the call sites you mean? Sure, I can do that. Yes. -- Nathan Bossart Amazon Web Services:

Re: bug: copy progress reporting of backends which run multiple COPYs

On Wed, May 08, 2024 at 10:07:15AM -0400, Robert Haas wrote: > I think you're hoping for too much. The progress reporting > infrastructure is fundamentally designed around the idea that there > can only be one progress-reporting operation in progress at a time. > For COPY, that is, I believe,

Re: ALTER EXTENSION SET SCHEMA versus dependent types

Nathan Bossart writes: > On Wed, May 08, 2024 at 07:42:18PM -0400, Tom Lane wrote: >> One positive reason for increasing the number of parameters is that >> that will be a clear API break for any outside callers, if there >> are any. If I just replace a bool with an enum, such callers might >>

Re: ALTER EXTENSION SET SCHEMA versus dependent types

On Wed, May 08, 2024 at 07:42:18PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Looks reasonable to me. The added test coverage seems particularly >> valuable. If I really wanted to nitpick, I might complain about the three >> consecutive Boolean parameters for

Re: ALTER EXTENSION SET SCHEMA versus dependent types

Nathan Bossart writes: > Looks reasonable to me. The added test coverage seems particularly > valuable. If I really wanted to nitpick, I might complain about the three > consecutive Boolean parameters for AlterTypeNamespaceInternal(), which > makes lines like > +

Re: ALTER EXTENSION SET SCHEMA versus dependent types

On Wed, May 08, 2024 at 05:52:31PM -0400, Tom Lane wrote: > The attached patch fixes up the code and adds a new test to > the test_extensions module. The fix basically is to skip the > pg_depend entries for dependent types, assuming that they'll > get dealt with when we process their parent

Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS make server crash, regress test fail.

David Rowley writes: > I'm fine with this one as it's the same as what I already mentioned > earlier. I had imagined doing bms_del_member(bms_copy ... but maybe > the compiler is able to optimise away the additional store. Likely, it > does not matter much as pallocing memory likely adds far

Re: Support tid range scan in parallel?

Thank you very much for the test and review. Greatly appreciated! > This now calls heap_setscanlimits() for the parallel version, it's > just that table_block_parallelscan_nextpage() does nothing to obey > those limits. yes, you are absolutely right. Though heap_setscanlimits() is now called by

Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS make server crash, regress test fail.

David Rowley writes: > On Thu, 9 May 2024 at 06:49, Tom Lane wrote: >> BTW, now that I've wrapped my head around what's happening here, >> I believe that -DREALLOCATE_BITMAPSETS is introducing a bug where >> there was none before. The changes that left-join removal makes >> won't cause any of

Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS make server crash, regress test fail.

On Thu, 9 May 2024 at 06:24, Tom Lane wrote: > I like alternative-2.patch a lot better, not least because it > only adds cycles when join removal actually fires. Basically > this is putting the onus on the data structure modifier to > cope with shared bitmapsets, rather than trying to say that >

Re: 2024-05-09 release announcement draft

On 5/8/24 5:44 PM, David Rowley wrote: On Thu, 9 May 2024 at 04:17, Jonathan S. Katz wrote: * Fix how [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) handles multiple [`VALUES`](https://www.postgresql.org/docs/current/sql-values.html) rows into a target column that is a

Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS make server crash, regress test fail.

On Thu, 9 May 2024 at 06:49, Tom Lane wrote: > BTW, now that I've wrapped my head around what's happening here, > I believe that -DREALLOCATE_BITMAPSETS is introducing a bug where > there was none before. The changes that left-join removal makes > won't cause any of these sets to go to empty, so

ALTER EXTENSION SET SCHEMA versus dependent types

I happened to notice that the comment for AlterObjectNamespace_oid claims that * ... it doesn't have to deal with certain special cases * such as not wanting to process array types --- those should never * be direct members of an extension anyway. This struck me as probably broken in the wake

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Thu, May 9, 2024 at 12:37 AM Justin Pryzby wrote: > > On Wed, May 08, 2024 at 09:00:10PM +0300, Alexander Korotkov wrote: > > On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov > > wrote: > > > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote: > > > > On Wed, May 01, 2024 at 10:51:24PM

Re: 2024-05-09 release announcement draft

On Thu, 9 May 2024 at 04:17, Jonathan S. Katz wrote: > * Fix how > [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) > handles multiple > [`VALUES`](https://www.postgresql.org/docs/current/sql-values.html) rows > into a target column that is a domain over an array or composite

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Wed, May 08, 2024 at 09:00:10PM +0300, Alexander Korotkov wrote: > On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov > wrote: > > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote: > > > On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote: > > > > 30.04.2024 23:15, Justin Pryzby

Re: cataloguing NOT NULL constraints

On 2024-May-07, Kyotaro Horiguchi wrote: > Hello, > > At Wed, 1 May 2024 19:49:35 +0200, Alvaro Herrera > wrote in > > Here are two patches that I intend to push soon (hopefully tomorrow). > > This commit added and edited two error messages, resulting in using > slightly different wordings

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Wed, May 1, 2024 at 12:14 AM Dmitry Koval wrote: > 30.04.2024 6:00, Alexander Lakhin пишет: > > Maybe I'm doing something wrong, but the following script: > > CREATE TABLE t (i int, PRIMARY KEY(i)) PARTITION BY RANGE (i); > > CREATE TABLE tp_0 PARTITION OF t FOR VALUES FROM (0) TO (1); > >

Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall

Nathan Bossart writes: > Thanks for looking. I noticed that the version check is unnecessary since > we always use the new binary's pg_dump[all], so I removed that in v2. +1 regards, tom lane

Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS make server crash, regress test fail.

BTW, now that I've wrapped my head around what's happening here, I believe that -DREALLOCATE_BITMAPSETS is introducing a bug where there was none before. The changes that left-join removal makes won't cause any of these sets to go to empty, so the bms_del_member calls won't free the sets but just

Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall

On Wed, May 08, 2024 at 10:09:46AM +0200, Peter Eisentraut wrote: > On 03.05.24 19:13, Nathan Bossart wrote: >> This is likely small potatoes compared to some of the other >> pg_upgrade-related improvements I've proposed [0] [1] or plan to propose, >> but this is easy enough, and I already wrote

Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS make server crash, regress test fail.

I traced down the other failure I was seeing in check-world, and found that it came from deconstruct_distribute doing this: distribute_quals_to_rels(root, my_quals, jtitem, sjinfo,

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov wrote: > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote: > > On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote: > > > 30.04.2024 23:15, Justin Pryzby пишет: > > > > Is this issue already fixed ? > > > > I wasn't able to reproduce

Re: New GUC autovacuum_max_threshold ?

> This is about how I feel, too. In any case, I +1'd a higher default > because I think we need to be pretty conservative with these changes, at > least until we have a better prioritization strategy. While folks may opt > to set this value super low, I think that's more likely to lead to some >

Re: 2024-05-09 release announcement draft

On 5/7/24 12:16 AM, Tom Lane wrote: David Rowley writes: Why not "Fix INSERT with multi-row VALUES clauses ..."? To my mind, the VALUES clause is the data source for INSERT, so "from" seems appropriate. I'm not going to argue hard about it. OK, so I've read through this a few times and

Re: Fix for recursive plpython triggers

Andreas Karlsson writes: > I found this issue while reading the code, so am very unclear if there > is any sane code which could trigger it. > In the example below the recursive call to f('int') changes the return > type of the f('text') call causing it to fail. > # CREATE OR REPLACE FUNCTION

Re: UUID v7

> On 3 May 2024, at 11:18, Andrey M. Borodin wrote: > > RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor, > and now should be published. It's RFC now. https://datatracker.ietf.org/doc/rfc9562/ Best regards, Andrey Borodin.

Re: Trigger violates foreign key constraint

Aleksander Alekseev writes: >> 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

Re: PERIOD foreign key feature

On Wed, May 8, 2024 at 02:29:34PM +0200, Peter Eisentraut wrote: > > > Finally, if the foreign key has a PERIOD column_name specification > > > the corresponding refcolumn, if present, must also be marked > > > PERIOD.  If the refcolumn clause is omitted, and thus the reftable's > > > primary key

Re: CREATE DATABASE with filesystem cloning

Hi, On Wed, 8 May 2024 at 16:58, Robert Haas wrote: > > On Tue, May 7, 2024 at 8:00 AM Nazir Bilal Yavuz wrote: > > We had an off-list talk with Thomas and we thought making this option > > GUC instead of SQL command level could solve this problem. > > > > I am posting a new rebased version of

Re: bug: copy progress reporting of backends which run multiple COPYs

On Tue, May 7, 2024 at 9:12 PM Michael Paquier wrote: > FWIW, I'm rather annoyed by the fact that we rely on the ParseState to > decide if reporting should happen or not. file_fdw tells, even if > that's accidental, that status reporting can be useful if working on a > single table. So,

Re: AIX support

On Wed, May 8, 2024 at 03:44:12PM +0200, Peter Eisentraut wrote: > On 08.05.24 13:39, Sriram RK wrote: > > We would like to understand your inputs/plans on reverting the changes > > for AIX. > > I think the ship has sailed for PG17. The way forward would be that you > submit a patch for new,

Re: [PATCH] json_lex_string: don't overread on bad UTF8

On Tue, May 7, 2024 at 10:31 PM Michael Paquier wrote: > But looking closer, I can see that in the JSON_INVALID_TOKEN case, > when !tok_done, we set token_terminator to point to the end of the > token, and that would include an incomplete byte sequence like in your > case. :/ Ah, I see what

Re: CREATE DATABASE with filesystem cloning

On Tue, May 7, 2024 at 8:00 AM Nazir Bilal Yavuz wrote: > We had an off-list talk with Thomas and we thought making this option > GUC instead of SQL command level could solve this problem. > > I am posting a new rebased version of the patch with some important changes: > > *

Re: SQL:2011 application time

On 30.04.24 18:39, Paul Jungwirth wrote: On 4/30/24 09:24, Robert Haas wrote: Peter, could you have a look at http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com and express an opinion about whether each of those proposals are (a) good or bad ideas and (b) whether

Re: Fix parallel vacuum buffer usage reporting

On Fri, May 3, 2024 at 3:41 PM Anthonin Bonnefoy wrote: > > On Wed, May 1, 2024 at 5:37 AM Masahiko Sawada wrote: >> >> Thank you for further testing! I've pushed the patch. > > Thanks! > > Here is the rebased version for the follow-up patch removing VacuumPage > variables. Though I'm not sure

Re: AIX support

On 08.05.24 13:39, Sriram RK wrote: We would like to understand your inputs/plans on reverting the changes for AIX. I think the ship has sailed for PG17. The way forward would be that you submit a patch for new, modernized AIX support for PG18.

Re: CREATE DATABASE with filesystem cloning

Em qua., 8 de mai. de 2024 às 10:06, Nazir Bilal Yavuz escreveu: > Hi, > > On Wed, 8 May 2024 at 15:23, Ranier Vilela wrote: > > > > Em qua., 8 de mai. de 2024 às 08:42, Nazir Bilal Yavuz < > byavu...@gmail.com> escreveu: > >> > >> Hi, > >> > >> On Wed, 8 May 2024 at 14:16, Ranier Vilela

Re: CREATE DATABASE with filesystem cloning

Hi, On Wed, 8 May 2024 at 15:23, Ranier Vilela wrote: > > Em qua., 8 de mai. de 2024 às 08:42, Nazir Bilal Yavuz > escreveu: >> >> Hi, >> >> On Wed, 8 May 2024 at 14:16, Ranier Vilela wrote: >> > >> > >> > Em qua., 8 de mai. de 2024 às 04:37, Nazir Bilal Yavuz >> > escreveu: >> >> >> >> Hi

Re: PERIOD foreign key feature

On 07.05.24 18:43, Paul Jungwirth wrote: On 5/7/24 08:23, David G. Johnston wrote: On Tue, May 7, 2024 at 7:54 AM Bruce Momjian > wrote:     In the two marked lines, it says "if one side of the foreign key uses     PERIOD, the other side must too."  However, looking at

Re: CREATE DATABASE with filesystem cloning

Em qua., 8 de mai. de 2024 às 08:42, Nazir Bilal Yavuz escreveu: > Hi, > > On Wed, 8 May 2024 at 14:16, Ranier Vilela wrote: > > > > > > Em qua., 8 de mai. de 2024 às 04:37, Nazir Bilal Yavuz < > byavu...@gmail.com> escreveu: > >> > >> Hi Ranier, > >> > >> Thanks for looking into this! > >> >

RE: Pgoutput not capturing the generated columns

Dear Shubham, Thanks for creating a patch! Here are high-level comments. 1. Please document the feature. If it is hard to describe, we should change the API. 2. Currently, the option is implemented as streaming option. Are there any reasons to choose the way? Another approach is to implement

Re: CREATE DATABASE with filesystem cloning

Hi, On Wed, 8 May 2024 at 14:16, Ranier Vilela wrote: > > > Em qua., 8 de mai. de 2024 às 04:37, Nazir Bilal Yavuz > escreveu: >> >> Hi Ranier, >> >> Thanks for looking into this! >> >> I am not sure why but your reply does not show up in the thread, so I >> copied your reply and answered it

Re: AIX support

Hi Team, We have the AIX node ready in OSU lab, and the branches 15 and 16 got build on the node. We had raised a request to register this node as buildfarm member. Yet to receive the approval. We would like to understand your inputs/plans on reverting the changes for AIX. Thanks, Sriram.

Re: CREATE DATABASE with filesystem cloning

Em qua., 8 de mai. de 2024 às 04:37, Nazir Bilal Yavuz escreveu: > Hi Ranier, > > Thanks for looking into this! > > I am not sure why but your reply does not show up in the thread, so I > copied your reply and answered it in the thread for visibility. > > On Tue, 7 May 2024 at 16:28, Ranier

Re: Expand applicability of aggregate's sortop optimization

Matthias van de Meent writes: > PFA the small patch that implements this. I don't have enough knowledge to have an opinion on most of the patch other than it looks okay at a glance, but the list API usage could be updated to more modern variants: > diff --git

Expand applicability of aggregate's sortop optimization

Hi, As you may know, aggregates like SELECT MIN(unique1) FROM tenk1; are rewritten as SELECT unique1 FROM tenk1 ORDER BY unique1 USING < LIMIT 1; by using the optional sortop field in the aggregator. However, this optimization is disabled for clauses that in itself have an ORDER BY clause such as

Re: Synchronizing slots from primary to standby

Hi, On Mon, Apr 29, 2024 at 11:58:09AM +, Zhijie Hou (Fujitsu) wrote: > On Monday, April 29, 2024 5:11 PM shveta malik wrote: > > > > On Mon, Apr 29, 2024 at 11:38 AM shveta malik > > wrote: > > > > > > On Mon, Apr 29, 2024 at 10:57 AM Zhijie Hou (Fujitsu) > > > wrote: > > > > > > > > On

Re: A problem about partitionwise join

On Fri, May 3, 2024 at 9:31 PM Robert Haas wrote: > On Fri, May 3, 2024 at 7:47 AM Richard Guo wrote: > > I think one concern regarding performance cost is that the function > > exprs_known_equal() would be called O(N^2) times, where N is the number > > of partition key expressions. But I

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

Dear Peter, Thanks for reviewing! Here are updated patches. I updated patches only for HEAD. > == > Commit message > > 1. > This patch allows user to alter two_phase option > > /allows user/allows the user/ > > /to alter two_phase option/to alter the 'two_phase' option/ Fixed. > ==

Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall

On 03.05.24 19:13, Nathan Bossart wrote: This is likely small potatoes compared to some of the other pg_upgrade-related improvements I've proposed [0] [1] or plan to propose, but this is easy enough, and I already wrote the patch, so here it is. AFAICT there's no reason to bother syncing these

Re: CREATE DATABASE with filesystem cloning

Hi Ranier, Thanks for looking into this! I am not sure why but your reply does not show up in the thread, so I copied your reply and answered it in the thread for visibility. On Tue, 7 May 2024 at 16:28, Ranier Vilela wrote: > > I know it's coming from copy-and-paste, but > I believe the flags

Re: Pgoutput not capturing the generated columns

On Wed, May 8, 2024 at 11:39 AM Rajendra Kumar Dangwal wrote: > > Hi PG Hackers. > > We are interested in enhancing the functionality of the pgoutput plugin by > adding support for generated columns. > Could you please guide us on the necessary steps to achieve this? > Additionally, do you have

Re: Fix for recursive plpython triggers

On 5/4/24 10:16 PM, Tom Lane wrote: This fixes bug #18456 [1]. Since we're in back-branch release freeze, I'll just park it for the moment. But I think we should shove it in once the freeze lifts so it's in 17beta1. There is a similar issue with the return type (at least if it is a generic