Re: Psql meta-command conninfo+

On Thursday, October 3, 2024, Hunaid Sohail wrote: > > > Authenticated User: The name of the user returned by PQuser(), indicating > the user who initiated or authenticated the current database connection. > Session User: The session user's name, which is initially the same as the > authenticated

Re: Psql meta-command conninfo+

Hi, On Thu, Oct 3, 2024 at 1:39 PM Maiquel Grassi wrote: > >I thought it would be nice to have a description that tells how both > >Session and Authenticated users differ. IMHO *only* a reference to > >PQuser() doesn't say much, but others might be ok with it. So let's see > >what the other revi

Re: Pgoutput not capturing the generated columns

Hi Shubham, I don't have any new comments for the patch v36-0002. But, according to my records, there are multiple old comments not yet addressed for this patch. I am giving reminders for those below so they don't get accidentally overlooked. Please re-confirm and at the next posted version please

Re: Pgoutput not capturing the generated columns

Hi Shubham, here are my review comments for v36-0001. == 1. General - merge patches It is long past due when patches 0001 and 0002 should've been merged. AFAIK the split was only because historically these parts had different authors. But, keeping them separated is not helpful anymore.

Re: Rename PageData to XLogPageData

On Thu, Oct 03, 2024 at 01:31:19PM +0200, Peter Eisentraut wrote: > Sounds good. Here is an updated version. Good idea. What you have sent here looks good to me. -- Michael signature.asc Description: PGP signature

Re: query_id, pg_stat_activity, extended query protocol

On Thu, Oct 03, 2024 at 10:00:00PM +0300, Alexander Lakhin wrote: > I've managed to falsify the Assert in ExecutorRun() with the following: > SET compute_query_id = 'off'; > SET track_activities = 'off'; > > CALL p2(0); > > CALL p2(1); Fun. This manipulates the session to force the state of the

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

On 10/4/24 03:15, Peter Geoghegan wrote: On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov wrote: I think this patchset got much better, and it could possible be committed after another round of cleanup and comment/docs improvement. It would be very kind if you share your view on the decisions

Re: Retire support for OpenSSL 1.1.1 due to raised API requirements

On Thu, Oct 03, 2024 at 08:54:49AM -0700, Jacob Champion wrote: > On Thu, Oct 3, 2024 at 3:17 AM Daniel Gustafsson wrote: >> We don't explicitly mention which libressl version we support, if we raise it >> as proposed here then perhaps it's a good time to state that in the docs. > > +1 It's pret

Re: [BUG FIX]Connection fails with whitespace after keepalives parameter value

On Thu, Oct 03, 2024 at 08:12:28PM -0400, Tom Lane wrote: > OK, if there's no objections let's push both remaining patches > to HEAD only. WFM. -- Michael signature.asc Description: PGP signature

Re: allowing extensions to control planner behavior

On 10/4/24 01:35, Robert Haas wrote: On Mon, Sep 30, 2024 at 5:50 AM Andrei Lepikhov wrote: In attachment - hooks for add_path and add_partial_path. As you can see, because of differences in these routines hooks also implemented differently. Also the compare_path_costs_fuzzily is exported, but

Re: Should rolpassword be toastable?

"Jonathan S. Katz" writes: > I think Tom's initial suggestion (BLCKSZ/2) is better than 256, given we > really don't know what' out there in the wild, and this could end up > being a breaking change. Every other type in pg_authid is pretty small. I'm having second thoughts about that though, b

Function for listing pg_wal/summaries directory

Hi, While WAL summaries feature and some support functions have been added in version 17, merely listing the contents of the pg_wal/summaries directory is missing. As discussed in the pg_ls_archive_status() discussion, it would be convenient to add pg_ls_summariesdir() that lists the contents

Re: Should rolpassword be toastable?

On 10/3/24 7:29 PM, Jacob Champion wrote: On Thu, Oct 3, 2024 at 3:25 PM Tom Lane wrote: Nathan Bossart writes: I don't mind proceeding with the patch if there is strong support for it. I wavered only because it's hard to be confident that we are choosing the right limit. I'm not that fuss

Re: bgwrite process is too lazy

Hi Andres > It's implied, but to make it more explicit: One big efficiency advantage of > writes by checkpointer is that they are sorted and can often be combined into > larger writes. That's often a lot more efficient: For network attached storage > it saves you iops, for local SSDs it's much fr

Re: [BUG FIX]Connection fails with whitespace after keepalives parameter value

Michael Paquier writes: > On Thu, Oct 03, 2024 at 11:57:16AM -0400, Tom Lane wrote: >> I don't have a strong opinion one way or the other about whether >> we should make libpq permissive about extra spaces (as per >> Michael's patch). I guess you could argue that all of these >> fixes are consist

Re: [BUG FIX]Connection fails with whitespace after keepalives parameter value

On Thu, Oct 03, 2024 at 11:57:16AM -0400, Tom Lane wrote: > I don't have a strong opinion one way or the other about whether > we should make libpq permissive about extra spaces (as per > Michael's patch). I guess you could argue that all of these > fixes are consistent with the principle of "be c

Re: Should rolpassword be toastable?

On Thu, Oct 3, 2024 at 3:25 PM Tom Lane wrote: > > Nathan Bossart writes: > > I don't mind proceeding with the patch if there is strong support for it. > > I wavered only because it's hard to be confident that we are choosing the > > right limit. > > I'm not that fussed about it; surely 256 is mo

Re: Should rolpassword be toastable?

Nathan Bossart writes: > I don't mind proceeding with the patch if there is strong support for it. > I wavered only because it's hard to be confident that we are choosing the > right limit. I'm not that fussed about it; surely 256 is more than anyone is using? If not, we'll get push-back and then

Re: Should rolpassword be toastable?

On Thu, Oct 03, 2024 at 05:39:06PM -0400, Tom Lane wrote: > I agree with the idea that complaining about the password being too > long is far more intelligible than that. Another problem with > leaving it as it stands in HEAD is that the effective limit is now > platform-specific, if not indeed de

Re: On disable_cost

On Fri, 4 Oct 2024 at 02:15, Robert Haas wrote: > robert.haas=# explain with recursive foo as (select count(*) from > pgbench_accounts union all select aid from pgbench_accounts a, foo > where aid > foo.count) select * from pgbench_accounts, foo where aid = > foo.count; > You might expect that th

Re: Should rolpassword be toastable?

Nathan Bossart writes: > For the reasons discussed upthread [0], I can't bring myself to add an > arbitrary limit to the password hash length. I am going to leave 0001 > uncommitted for now. > [0] https://postgr.es/m/Zu2eT2H8OT3OXauc%40nathan I'm confused, as in [0] you said >> ... But on the

Re: Should rolpassword be toastable?

On Sat, Sep 21, 2024 at 03:25:54PM -0500, Nathan Bossart wrote: > Thanks for reviewing. I went ahead and committed 0002 since it seems like > there's consensus on that one. I've attached a rebased version of 0001 > with s/characters/bytes. For the reasons discussed upthread [0], I can't bring my

Re: Make tuple deformation faster

Hi, A few weeks ago David and I discussed this patch. We were curious *why* the flags approach was slower. It turns out that, at least on my machine, this is just a compiler optimization issue. Putting a pg_compiler_barrier() just after: > for (; attnum < natts; attnum++) > { > -

Re: Enable data checksums by default

On Tue, Oct 01, 2024 at 11:15:02AM -0400, Peter Eisentraut wrote: > I have committed 0001 (the new option) and 0004 (the docs tweak). I think > there is consensus for the rest, too, but I'll leave it for a few more days > to think about. I guess the test failure has to be addressed. Here is a re

Re: Replace IN VALUES with ANY in WHERE clauses during optimization

Laurenz Albe writes: > I wonder if it is worth the extra planning time to detect and improve > such queries. I'm skeptical too. I'm *very* skeptical of implementing it in the grammar as shown here --- I'd go so far as to say that that approach cannot be accepted. That's far too early, and it ri

Re: Replace IN VALUES with ANY in WHERE clauses during optimization

On Thu, 2024-10-03 at 23:10 +0300, Alena Rybakina wrote: > On 03.10.2024 22:52, Ivan Kush wrote: > > > > Hello, hackers! I with my friends propose the patch to replace IN > > VALUES to ANY in WHERE clauses. > > > > # Intro > > > > The `VALUES` in the `IN VALUES` construct is replaced with with

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

On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov wrote: > I think this patchset got much better, and it could possible be > committed after another round of cleanup and comment/docs improvement. > It would be very kind if you share your view on the decisions made in > this patchset. I do think t

Re: Replace IN VALUES with ANY in WHERE clauses during optimization

Hi! On 03.10.2024 22:52, Ivan Kush wrote: Hello, hackers! I with my friends propose the patch to replace IN VALUES to ANY in WHERE clauses. # Intro The `VALUES` in the `IN VALUES` construct is replaced with with an array of values when `VALUES` contains 1 column. In the end it will be rep

Re: On disable_cost

On Thu, 2024-10-03 at 14:24 -0400, Robert Haas wrote: > On Thu, Oct 3, 2024 at 1:35 PM Alena Rybakina > wrote: > > I prepared a patch that includes the information we can add. > > One general thing to think about is that we really document very > little about EXPLAIN. That might not be good, but

Replace IN VALUES with ANY in WHERE clauses during optimization

Hello, hackers! I with my friends propose the patch to replace IN VALUES to ANY in WHERE clauses. # Intro The `VALUES` in the `IN VALUES` construct is replaced with with an array of values when `VALUES` contains 1 column. In the end it will be replaced with ANY by the existing function make

Re: bgwrite process is too lazy

Hi, On 2024-10-02 18:36:44 +0200, Tomas Vondra wrote: > On 10/2/24 17:02, Tony Wayne wrote: > > > > > > On Wed, Oct 2, 2024 at 8:14 PM Laurenz Albe > > wrote: > > > > On Wed, 2024-10-02 at 16:48 +0800, wenhui qiu wrote: > > > Whenever I check the checkp

Re: pg_basebackup and error messages dependent on the order of the arguments

Robert Haas writes: > On Wed, Oct 2, 2024 at 6:00 AM Daniel Westermann (DWE) > wrote: >> Maybe checking if a valid "-D" or "--pgdata" was given and return a more >> generic error message would be an option? > It doesn't really seem reasonable to me to make the tools guess > whether somebody lef

Re: pg_basebackup and error messages dependent on the order of the arguments

On Wed, Oct 2, 2024 at 6:00 AM Daniel Westermann (DWE) wrote: > Maybe checking if a valid "-D" or "--pgdata" was given and return a more > generic error message would be an option? It doesn't really seem reasonable to me to make the tools guess whether somebody left out the argument to an option

Re: query_id, pg_stat_activity, extended query protocol

Hello Michael, 02.10.2024 06:29, Michael Paquier wrote: On Wed, Oct 02, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote: Fortunately, it's still pretty warm here, so I'm wearing T-shirt and my sleeve isn't long enough for that, but if you gave me 2-3 days, I would focus on researching this are

Re: allowing extensions to control planner behavior

On Mon, Sep 30, 2024 at 5:50 AM Andrei Lepikhov wrote: > Being flexible, this approach is less invasive. Now, I use it to > implement heuristics demanded by clients for cases when the estimator > predicts only one row - usually, it means that the optimiser > underestimates cardinality. For example

Re: Using per-transaction memory contexts for storing decoded tuples

On Thu, Oct 3, 2024 at 2:46 AM Fujii Masao wrote: > > > > On 2024/10/03 13:47, Masahiko Sawada wrote: > >>> I agree that the overhead will be much less visible in real workloads. > >>> +1 to use a smaller block (i.e. 8kB). > > +1 > > > >>> It's easy to backpatch to old > >>> branches (if we agree)

Re: On disable_cost

On Thu, Oct 3, 2024 at 1:35 PM Alena Rybakina wrote: > I think you are right, most users will perceive this parameter as the number > of rejected paths, and not in any other way. > > To be honest, I don't have much experience writing documentation, but I think > we should add a little more infor

Re: On disable_cost

Overall, I think we need to do something here. There's no documentation about what Disabled Nodes means so we either need to make it easier to understand without documenting it or add something to the documents about it. If Laurenz, who has a huge amount of PostgreSQL experience didn't catch it, t

Re: pg_walsummary, Character-not-present-in-option

On Mon, Sep 30, 2024 at 12:08 PM Tom Lane wrote: > btsugieyuusuke writes: > >> Therefore, shouldn't “f:” and “w:” be removed? > > Looks like that to me too. Pushed. Thanks to Yusuke-san for the report and patch and to Tom for the commit. I vaguely recall that early in the development of pg_wals

Re: Enhance file_fdw to report processed and skipped tuples in COPY progress

Hi, On Thu, Oct 3, 2024 at 2:23 AM Fujii Masao wrote: > > Hi, > > Currently, file_fdw updates several columns in the pg_stat_progress_copy view, > like relid and bytes_processed, but it doesn't track tuples_processed or > tuples_skipped. Monitoring these would be particularly useful when handling

Re: [BUG FIX]Connection fails with whitespace after keepalives parameter value

I poked into the ecpg end of this and found that the extra space is coming from one production in ecpg.trailer that's carelessly using cat_str (which inserts spaces) instead of makeN_str (which doesn't). So it's pretty trivial to fix, as attached. I do not think we could rip out ECPGconnect's log

Re: Retire support for OpenSSL 1.1.1 due to raised API requirements

On Thu, Oct 3, 2024 at 3:17 AM Daniel Gustafsson wrote: > In the TLSv1.3 cipher suite thread it was brought up that this bump in minimum > version would bump the minimum version of libressl to 3.4, whcih corresponds > to > the OpenBSD 3.4 release (from October 2021). OpenBSD 7.0, that is. > We

Re: Enhance file_fdw to report processed and skipped tuples in COPY progress

On Thu, Oct 3, 2024 at 6:23 AM Fujii Masao wrote: > > Hi, > > Currently, file_fdw updates several columns in the pg_stat_progress_copy view, > like relid and bytes_processed, but it doesn't track tuples_processed or > tuples_skipped. Monitoring these would be particularly useful when handling > la

Re: make \d table Collation field showing domains collation if that attribute is type of domain.

jian he writes: > main changes: > @@ -1866,7 +1866,7 @@ describeOneTableDetails(const char *schemaname, > attrdef_col = cols++; > attnotnull_col = cols++; > appendPQExpBufferStr(&buf, ",\n (SELECT c.collname > FROM pg_catalog.pg_collation c, pg_cata

Re: Add new COPY option REJECT_LIMIT

On 2024/09/30 21:08, torikoshia wrote: Since defGetInt64() checks not only whether the input value exceeds the range of bigint but also input value is specified, attached v6 patch checks them by directly calling defGetInt64(). Thanks for updating the patch! But the patch no longer applied

Re: Add on_error and log_verbosity options to file_fdw

On 2024-10-03 18:03, Fujii Masao wrote: On 2024/10/03 13:23, Masahiko Sawada wrote: On Tue, Oct 1, 2024 at 11:34 PM Fujii Masao wrote: On 2024/10/02 9:27, Masahiko Sawada wrote: Sorry for being late in joining the review of this patch. Both 0001 and 0003 look good to me. I have two comments

make \d table Collation field showing domains collation if that attribute is type of domain.

$subject related demos: CREATE COLLATION case_insensitive (provider = icu, locale = '@colStrength=secondary', deterministic = false); create domain d_colli as text collate case_insensitive; create domain d_collc as d_colli collate "C"; create table s1(a d_colli); create table s2(a d_colli[] colla

Re: CI warnings test for 32 bit, and faster headerscheck

Thomas Munro writes: > Hmm, given that configure uses more time than compiling (assuming 100% > ccache hits) and is woefully serial, I wonder what ingredients you'd > need to hash to have bulletproof cache invalidation for a persistent > configure cache, ie that survives between runs. The buildfa

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On Wed, Oct 2, 2024 at 10:02 AM Masahiko Sawada wrote: > > On Tue, Oct 1, 2024 at 8:57 PM Tom Lane wrote: > > > > Noah Misch writes: > > > On Tue, Oct 01, 2024 at 11:55:48AM -0700, Masahiko Sawada wrote: > > >> Considering that the population of database cluster signedness will > > >> converge t

Re: On disable_cost

On 03.10.2024 01:44, David Rowley wrote: On Thu, 3 Oct 2024 at 08:41, Alena Rybakina wrote: I may have misunderstood your message, but disabled nodes number must propagate up the tree, otherwise it will be incorrect. I think there are two misunderstandings on this thread: 1) You're misunders

Re: On disable_cost

On Wed, Oct 2, 2024 at 8:11 PM David Rowley wrote: > I can't quite find the area you're talking about where the > disabled_nodes don't propagate through subquery levels. Looking at > cost_subqueryscan(), I see propagation of disabled_nodes. If the > SubqueryScan node isn't present then the propaga

Re: pg_verifybackup: TAR format backup verification

On Wed, Oct 2, 2024 at 8:30 PM Tom Lane wrote: > Nope, it was my testing error: I supposed that this patch only > affected pg_combinebackup and pg_verifybackup, so I only > recompiled those modules not the whole tree. But there's one > more place with a json_manifest_per_file_callback callback :-

Re: Do not lock temp relations

On Mon, 30 Sept 2024 at 18:05, Tom Lane wrote: > Yes. Our implementation restrictions preclude access to the contents > of another session's temp tables, but it is not forbidden to do DDL > on them so long as no content access is required. (Without this, > it'd be problematic for example to cle

Re: Rename PageData to XLogPageData

On 02.10.24 19:02, Heikki Linnakangas wrote: This patch renames that type to a more specific name XLogPageData. This makes room for possibly adding another PageData type with the earlier meaning, but that's not done here.  But I think even without that, this patch is a useful little cleanup th

Re: Possibilities on code change to implement pseudodatatypes

On Mon, Sep 30, 2024 at 10:19 AM Vinícius Abrahão wrote: > On Mon, Sep 30, 2024 at 9:01 AM Vinícius Abrahão > wrote: > >> Greetings >> >> I understand the complexity of implementing a pseudo data type when >> passing it over parameters, or using it when creating an object. >> vide: git grep pseu

Re: Pgoutput not capturing the generated columns

On Mon, Sep 30, 2024 at 12:56 PM Peter Smith wrote: > > Hi Shubham. Here are my review comment for patch v34-0002. > > == > doc/src/sgml/ref/create_publication.sgml > > 1. > + > + This parameter can only be set true if > copy_data is > + set to false. > + > >

Re: Retire support for OpenSSL 1.1.1 due to raised API requirements

> On 10 Sep 2024, at 10:44, Daniel Gustafsson wrote: > This change will be committed together with the TLSv1.3 cipher suite pathcset, > just wanted to bring it up here and not hide it in another thread. In the TLSv1.3 cipher suite thread it was brought up that this bump in minimum version would

RE: long-standing data loss bug in initial sync of logical replication

Dear Shlok-san, Thanks for updating the patch. Here are comments. 1. I feel the name of SnapBuildDistributeNewCatalogSnapshot() should be updated because it distributes two objects: catalog snapshot and invalidation messages. Do you have good one in your mind? I considered "SnapBuildDistribute

Re: [PATCH] Check for TupleTableSlot nullness before dereferencing

> On 3 Oct 2024, at 09:47, Alexander Kuznetsov wrote: > > Hello everyone, > > I'd like to propose adding check for nullness of > TupleTableSlot before dereferencing it in /src/backend/executor/nodeAgg.c > > It is done in the same manner other TupleTableSlots are checked, > but was probably left

Re: Using per-transaction memory contexts for storing decoded tuples

On 2024/10/03 13:47, Masahiko Sawada wrote: I agree that the overhead will be much less visible in real workloads. +1 to use a smaller block (i.e. 8kB). +1 It's easy to backpatch to old branches (if we agree) +1 It seems that only reorderbuffer.c uses the LARGE macro so that it can b

Re: Patch: Show queries of processes holding a lock

On Thu, Oct 3, 2024 at 3:58 AM David Rowley wrote: > > On Tue, 1 Oct 2024 at 21:04, Alexey Orlov wrote: > > session 1: > > CREATE TABLE foo (val integer); > > INSERT INTO foo (val) VALUES (1); > > BEGIN; > > UPDATE foo SET val = 3; > > > > session 2: > > BEGIN; > > UPDATE TABLE foo SET val = 2; >

Enhance file_fdw to report processed and skipped tuples in COPY progress

Hi, Currently, file_fdw updates several columns in the pg_stat_progress_copy view, like relid and bytes_processed, but it doesn't track tuples_processed or tuples_skipped. Monitoring these would be particularly useful when handling large data sets via file_fdw, as it helps track the progress of s

Re: Return pg_control from pg_backup_stop().

On 10/3/24 07:45, Michael Paquier wrote: On Wed, Oct 02, 2024 at 09:03:27AM +, David Steele wrote: On 10/2/24 10:11, Michael Paquier wrote: I can definitely see us making other updates to pg_control so I would rather keep this logic centralized, even though it is not too complicated at th

Re: Add on_error and log_verbosity options to file_fdw

On 2024/10/03 13:23, Masahiko Sawada wrote: On Tue, Oct 1, 2024 at 11:34 PM Fujii Masao wrote: On 2024/10/02 9:27, Masahiko Sawada wrote: Sorry for being late in joining the review of this patch. Both 0001 and 0003 look good to me. I have two comments on the 0002 patch: Thanks for the

RE: Psql meta-command conninfo+

>I thought it would be nice to have a description that tells how both >Session and Authenticated users differ. IMHO *only* a reference to >PQuser() doesn't say much, but others might be ok with it. So let's see >what the other reviewers say. Hi everyone, I believe the difference between Session an

[PATCH] Check for TupleTableSlot nullness before dereferencing

Hello everyone, I'd like to propose adding check for nullness of TupleTableSlot before dereferencing it in /src/backend/executor/nodeAgg.c It is done in the same manner other TupleTableSlots are checked, but was probably left unseen because slot1 and slot2 variables can be swapped during functio

Re: Add new COPY option REJECT_LIMIT

> I'm wondering if we can use the wording maxerror as in the attached > patch. > + +REJECT_LIMIT + + + Specifies the maximum number of errors tolerated while converting a + column's input value to its data type, when ON_ERROR is + set to ignore. + If the input c

Re: not null constraints, again

I thought SearchSysCacheCopyAttNum is expensive. Relation->rd_att is enough for checking attnotnull. What do you think of the following refactoring of set_attnotnull? static void set_attnotnull(List **wqueue, Relation rel, AttrNumber attnum, LOCKMODE lockmode) { Oid

Re: Add parallel columns for pg_stat_statements

On Thu, Aug 29, 2024 at 10:08:23PM +0200, Guillaume Lelarge wrote: > This patch was a bit discussed on [1], and with more details on [2]. It's > based on another patch sent in 2022 (see [3]). It introduces seven new > columns in pg_stat_statements: > > * parallelized_queries_planned, number of ti