Re: Fix slot synchronization with two_phase decoding enabled

HI, Please find the patches attached for all three approaches. On Wed, Apr 9, 2025 at 10:45 AM Zhijie Hou (Fujitsu) wrote: > > On Thu, Apr 3, 2025 at 3:16 PM Zhijie Hou (Fujitsu) wrote: > > > > On Thu, Apr 3, 2025 at 1:38 PM Masahiko Sawada wrote: > > > > > > > > On Wed, Apr 2, 2025 at 7:58 PM A

disallow ALTER VIEW SET DEFAULT when the corresponding base relation column is a generated column

hi. CREATE TABLE gtest1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED); CREATE VIEW gtest1v AS SELECT * FROM gtest1; ALTER VIEW gtest1v ALTER COLUMN b SET DEFAULT 100; INSERT INTO gtest1v VALUES (8, DEFAULT) returning *; ERROR: cannot insert a non-DEFAULT value into column "b" DETAIL: Column

Regression test fails when 1) old PG is installed and 2) meson/ninja build is used

Dear hackers, While creating patches for older branches I found the $SUBJECT. I do not have much knowledge for meson thus I'm not sure it is intentional. Reproducer === I could reproduce the failure with steps: 1. install old PG, e.g., PG16. To your system. .so file must be put on your $$L

Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions

Hi, On Thu, 10 Apr 2025 at 16:50, Bertrand Drouvot wrote: > On Tue, Apr 08, 2025 at 02:40:52AM -0400, Andres Freund wrote: > > I think it's ok for now. It might be worth doing a larger redesign of the > > pgbuffercache docs at some point... > > > > > > Pushed. > > > > > > Thanks for your patches

Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions

Hi, Thank you for looking into this! On Thu, 10 Apr 2025 at 23:06, Robert Haas wrote: > > On Tue, Mar 18, 2025 at 6:03 PM Aidar Imamov wrote: > > > for (int buf = 1; buf < NBuffers; buf++) > > Mb it would be more correct to use <= NBuffers? > > I agree that (int buf = 1; buf < NBuffers; buf++)

Re: Correct documentation for protocol version

On 2025/04/11 5:17, Dave Cramer wrote: No, you are correct. See new patch Thanks for updating the patch! - Identifies the message as a protocol version negotiation + Identifies the message as a protocol version negotiation. + The server sends this message if the req

Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

Hi, There is another thread [1] to add both pg_buffercache_evict_[relation | all] and pg_buffercache_mark_dirty[_all] functions to the pg_buffercache. I decided to create another thread as pg_buffercache_evict_[relation | all] functions are committed but pg_buffercache_mark_dirty[_all] functions s

Re: Correct documentation for protocol version

On Fri, 11 Apr 2025 at 05:05, Fujii Masao wrote: > > > On 2025/04/11 5:17, Dave Cramer wrote: > > No, you are correct. > > > > See new patch > > Thanks for updating the patch! > > - Identifies the message as a protocol version negotiation > + Identifies the message as a protocol v

Re: merge file_exists_in_directory and _fileExistsInDirectory functions and move into common file dumputils.c

On 2025-Apr-11, Michael Paquier wrote: > Perhaps we should just use a more centralized place, like file_utils.c > so as all frontends could benefit of it? I'm not sure about that. This code looks to be making too many assumptions that aren't acceptable for a general routine, such as complaining

Re: why there is not VACUUM FULL CONCURRENTLY?

Matheus Alcantara wrote: > Hi, > > On Tue, Apr 1, 2025 at 10:31 AM Antonin Houska wrote: > > One more version, hopefully to make cfbot happy (I missed the bug because I > > did not set the RELCACHE_FORCE_RELEASE macro in my environment.) > > Thanks for the new version! I'm starting to study th

Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.

> On 24 Mar 2025, at 20:31, Rahila Syed wrote: > Please find the attached updated and rebased patch. Thanks for this rebase, as was mentioned in the other thread I plan to get this committed fairly soon. A few comments on the code, all performed in the attached v3. + else + { +

Re: Silence resource leaks alerts

Thanks Michael, for looking at this. Em sex., 11 de abr. de 2025 às 02:09, Michael Paquier escreveu: > On Thu, Apr 10, 2025 at 03:10:02PM -0300, Ranier Vilela wrote: > > While it is arguable that this is a false warning, there is a benefit in > > moving the initialization of the string buffer,

Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions

On Fri, Apr 11, 2025 at 4:02 AM Nazir Bilal Yavuz wrote: > I understand your point. I did it like that because bufferids start > from 1 and go to NBuffers inclusive in the pg_buffercache view, so it > seems more natural to me to implement it like that. I am okay to > replace these loops with [1] t

Re: Silence resource leaks alerts

Em sex., 11 de abr. de 2025 às 02:37, Tom Lane escreveu: > Michael Paquier writes: > > On Thu, Apr 10, 2025 at 03:10:02PM -0300, Ranier Vilela wrote: > >> While it is arguable that this is a false warning, there is a benefit in > >> moving the initialization of the string buffer, silencing the w

Re: as per commit 643a1a61985bef2590496, move create/open dir code to function using switch case of pg_backup_directory.c file also

I don't understand why the routine is called "create_or_open_dir". In what sense does this open the directory? I think "check_or_create_dir" would be closer to what this seem to be doing. Is there no TOCTTOU bug in pg_dumpall because of the way this code is written? A malicious user that can cr

add some more error checks into _fileExistsInDirectory function to report "too long name" error

Hi, In another thread[1], Álvaro gave some feedback for _fileExistsInDirectory function for "too long name" error. Basically, in _fileExistsInDirectory function, we pass dirname and filename but we were checking only the combined length of these two names. Here, I am attaching a patch which will c

Re: merge file_exists_in_directory and _fileExistsInDirectory functions and move into common file dumputils.c

On Fri, 11 Apr 2025 at 10:21, Michael Paquier wrote: > > On Thu, Apr 10, 2025 at 10:41:33PM +0530, Mahendra Singh Thalor wrote: > > We have file_exists_in_directory function in pg_restore.c and same > > code we are using in _fileExistsInDirectory function in pg_backup_archiver.c > > also. > > Here

Re: add some more error checks into _fileExistsInDirectory function to report "too long name" error

> On 11 Apr 2025, at 14:26, Mahendra Singh Thalor wrote: > > Hi, > In another thread[1], Álvaro gave some feedback for _fileExistsInDirectory > function for "too long name" error. > Basically, in _fileExistsInDirectory function, we pass dirname and filename > but we were checking only the combi

Re: RFC: Allow EXPLAIN to Output Page Fault Information

On 2025-03-25 10:27, torikoshia wrote: On 2025-03-22 20:23, Jelte Fennema-Nio wrote: On Wed, 19 Mar 2025 at 14:15, torikoshia wrote: BTW based on your discussion, I thought this patch could not be merged anytime soon. Does that align with your understanding? Yeah, that aligns with my under

COALESCE with single argument looks like identity function

Hello everyone! I've noticed that COALESCE function doesn't converge to argument expression if it is alone in argument list of COALESCE as part simplification routine for expressions in planner. This might suppress further useful transformations when non-strict ops are required from some exp

Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions

Hi, On 2025-04-10 13:50:36 +, Bertrand Drouvot wrote: > Thanks for the patch! That sounds like a great addition. I was doing some > tests and did not see any issues. Also while doing the tests I thouhgt that it > could be useful to evict only from a subset of NUMA nodes (now that NUMA > awaren

Re: Correct documentation for protocol version

On 2025/04/11 18:27, Dave Cramer wrote: On Fri, 11 Apr 2025 at 05:05, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote: On 2025/04/11 5:17, Dave Cramer wrote: > No, you are correct. > > See new patch Thanks for updating the patch! -         Identifies th

Re: Regression test fails when 1) old PG is installed and 2) meson/ninja build is used

Hi, On 2025-04-11 07:53:07 +, Hayato Kuroda (Fujitsu) wrote: > Dear hackers, > > While creating patches for older branches I found the $SUBJECT. I do not have > much knowledge > for meson thus I'm not sure it is intentional. > Reproducer > === > I could reproduce the failure with steps:

Re: COALESCE with single argument looks like identity function

Maksim Milyutin writes: > I've noticed that COALESCE function doesn't converge to argument > expression if it is alone in argument list of COALESCE as part > simplification routine for expressions in planner. This might suppress > further useful transformations when non-strict ops are required

Re: disallow ALTER VIEW SET DEFAULT when the corresponding base relation column is a generated column

jian he writes: > CREATE TABLE gtest1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED); > CREATE VIEW gtest1v AS SELECT * FROM gtest1; > ALTER VIEW gtest1v ALTER COLUMN b SET DEFAULT 100; > INSERT INTO gtest1v VALUES (8, DEFAULT) returning *; > ERROR: cannot insert a non-DEFAULT value into colu

Conflicting updates of command progress

While working on [1] I realized that some field of pg_stat_progress_cluste has weird value. On closer look I found out that cluster_rel() indirectly calls index_build() and that overwrites the progress parameter. Following are the parameter values in the master branch: /* Phases of cluster (as adv

Re: Improve a few appendStringInfo calls new to v18

On Fri, Apr 11, 2025 at 10:40:57AM +1200, David Rowley wrote: > On Fri, 11 Apr 2025 at 02:51, Nathan Bossart wrote: >> This probably isn't v18 material, but this reminds me of my idea to change >> appendStringInfoString() into a macro for appendBinaryStringInfo() so that >> the compiler can remove

Re: Changing shared_buffers without restart

On Mon, Apr 7, 2025 at 2:13 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > Yes, you're right, plain dynamic Barrier does not ensure all available > processes will be synchronized. I was aware about the scenario you > describe, it's mentioned in commentaries for the resize function. I was > und

Re: Correct documentation for protocol version

On Fri, 11 Apr 2025 at 09:39, Fujii Masao wrote: > > > On 2025/04/11 18:27, Dave Cramer wrote: > > > > > > On Fri, 11 Apr 2025 at 05:05, Fujii Masao > wrote: > > > > > > > > On 2025/04/11 5:17, Dave Cramer wrote: > > > No, you are correct. > > >

Re: Correct documentation for protocol version

On Fri, 11 Apr 2025 at 22:57, Dave Cramer wrote: > Well this isn't quite true since if you request 3.0 and have invalid options > it will return 3.0, which is not the highest supported minor version. Probably good to update this section too then to be similarly correct as your already updated se

Re: Changing shared_buffers without restart

> On Fri, Apr 11, 2025 at 08:04:39PM GMT, Ashutosh Bapat wrote: > On Mon, Apr 7, 2025 at 2:13 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > > Yes, you're right, plain dynamic Barrier does not ensure all available > > processes will be synchronized. I was aware about the scenario you > > des

Re: stats.sql fails during installcheck on mac

> The code in xlog.c filters out the syncs for WAL_SYNC_METHOD_OPEN and > WAL_SYNC_METHOD_OPEN_DSYNC, wouldn't it be more consistent to do the > same in the code and the SQL test, using an IN clause with the two > values that block the syncs rather than a NOT IN clause with the three > values that

Re: Correct documentation for protocol version

On Fri, 11 Apr 2025 at 21:39, Fujii Masao wrote: > While checking the code in older branches, I noticed that the returned > protocol version is always the latest version supported by the server. > However, as we discussed, in master, the server may return the version > requested by the client. The

Re: Some problems regarding the self-join elimination code

On 4/10/25 14:39, Andrei Lepikhov wrote: On 4/10/25 13:36, Alexander Korotkov wrote: On Wed, Apr 9, 2025 at 10:39 AM Andrei Lepikhov wrote: It seems we are coming to the conclusion that join removal optimisation may do something out of ChangeVarNodes resposibility. Before further complicating

Re: Feature Recommendations for Logical Subscriptions

Amit Kapila, Yes, as you mentioned, but I’d like to add that when using the exclusion method for newly added columns, there’s no need to modify the publication. This is similar to how fields are automatically synchronized when columns are unspecified during initial setup. This is also a key reas

Re: Feature Recommendations for Logical Subscriptions

Another permission-related issue involves scenarios where multiple logical replication slots exist. If a replication slot grants full data access permissions and user accounts are not explicitly bound to specific slots, there could be security risks where accounts might connect to high-privilege

Re: Improve a few appendStringInfo calls new to v18

Peter Eisentraut writes: > Would it be useful to augment appendStringInfo() something like this: > if (VA_ARGS_NARGS() == 0) > return appendStringInfoString(str, fmt); That would change the behavior in edge cases, for instance appendStringInfo(str, "foo%%bar"). Maybe we'd never hit those,

Re: [PoC] Federated Authn/z with OAUTHBEARER

Jacob Champion: On Wed, Apr 9, 2025 at 4:42 PM Jelte Fennema-Nio wrote: I think your suggestion of not using any .so files would best there (from w user perspective). I'd be quite surprised if a static build still resulted in me having to manage shared library files anyway. Done this way in

someone else to do the list of acknowledgments

I would like for someone else to prepare the list of acknowledgments in the release notes this year. I have been preparing the list of acknowledgments in the release notes (example: [0]) since PostgreSQL 10 (launched from discussions at PGCon 2017 [1]). I'm looking to hand this off now, so that

Re: Things I don't like about \du's "Attributes" column

On Sun, Feb 9, 2025 at 2:11 AM Pavel Luzanov wrote: > > I don't understand from new commitfest transition guidance > what to do with status of commitfest entry in this case. > May be it needs to be closed. And in a case I will be able to propose > a new version, I will open a new entry. > > The c

Re: [PoC] Federated Authn/z with OAUTHBEARER

On 08.04.25 19:44, Jacob Champion wrote: Would anybody following along be opposed to a situation where - dynamiclib builds go through the dlopen() shim - staticlib builds always rely on statically linked symbols If this can be implemented in a straightforward way, that would be the best way, I

remove unnecessary explicit type conversion (to char) for appendStringInfoChar function calls

Hi, In the current master code, 3 places we are using appendStringInfoChar call with explicit type conversion into char. This is not needed as all other places, we are using direct character to append. --- a/src/backend/tcop/postgres.c +++ b/src/backend/tcop/postgres.c @@ -302,7 +302,7 @@ Interact

Re: disallow ALTER VIEW SET DEFAULT when the corresponding base relation column is a generated column

On Friday, April 11, 2025, Tom Lane wrote: > jian he writes: > > CREATE TABLE gtest1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED); > > CREATE VIEW gtest1v AS SELECT * FROM gtest1; > > ALTER VIEW gtest1v ALTER COLUMN b SET DEFAULT 100; > > > INSERT INTO gtest1v VALUES (8, DEFAULT) returning

Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote

On Thu, Apr 10, 2025 at 11:58:41PM +0530, Mahendra Singh Thalor wrote: > As per above discussions, for v18, we will not do any change to server > side to fix the issue of \n\r in database names. But as a cleanup > patch, we can give an alert to the user by "pg_upgrade --check". As > per current cod

Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.

Hi Daniel, Thank you for your review and code improvements. Please find below some observations. 1. dsm_unpin_mapping(dsm_segment *seg) + if (CurrentResourceOwner && IsResourceOwnerReleasing(CurrentResourceOwner)) + return; Given that the function can return without setting

Re: n_ins_since_vacuum stats for aborted transactions

I spent some time thinking about this today. > "The tuple counters below, except where noted, are incremented even if the > transaction aborts." I like this idea, and I think it fits good as a blurb under "27.2.2. Viewing Statistics" I suggest a slight re-write however. + + An aborted tran

Re: Horribly slow pg_upgrade performance with many Large Objects

On Tue, Apr 08, 2025 at 12:22:00PM -0500, Nathan Bossart wrote: > On Tue, Apr 08, 2025 at 01:07:09PM -0400, Tom Lane wrote: >> Nathan Bossart writes: >>> I do think it's worth considering going back to copying >>> pg_largobject_metadata's files for upgrades from v16 and newer. >> >> (If we do thi

Re: type cache cleanup improvements

On Tue, Oct 22, 2024 at 08:33:24PM +0300, Alexander Korotkov wrote: > On Tue, Oct 22, 2024 at 6:10 PM Pavel Borisov wrote: > > On Tue, 22 Oct 2024 at 11:34, Alexander Korotkov > > wrote: > >> I'm going to push this if no objections. (This became commit b85a9d0.) > + /* Call delete_rel_type

Re: Fixing various typos in comments and docs

> On 3 Mar 2025, at 01:39, Jacob Brazeal wrote: > > This patch fixes various typos I've found, most of them from recent commits. Thanks, I've applied the fixes for typos introduced during the v18 cycle. I did leave a few out from your patch though: > - Because not all statistics are not tr

New committer: Jacob Champion

The Core Team would like to extend our congratulations to Jacob Champion, who has accepted an invitation to become our newest PostgreSQL committer. Please join us in wishing Jacob much success and few reverts! Thanks, Jonathan OpenPGP_signature.asc Description: OpenPGP digital signature

Re: New committer: Jacob Champion

On 4/11/25 16:26, Jonathan S. Katz wrote: The Core Team would like to extend our congratulations to Jacob Champion, who has accepted an invitation to become our newest PostgreSQL committer. Please join us in wishing Jacob much success and few reverts! \o/ Congrats Jacob! -- Joe Conway Postgr

Re: New committer: Jacob Champion

On Fri, Apr 11, 2025 at 01:26:04PM -0700, Jonathan S. Katz wrote: > The Core Team would like to extend our congratulations to Jacob Champion, > who has accepted an invitation to become our newest PostgreSQL committer. > > Please join us in wishing Jacob much success and few reverts! Congrats! --

Re: Large expressions in indexes can't be stored (non-TOASTable)

On Wed, Apr 09, 2025 at 08:54:21PM -0300, Euler Taveira wrote: > LGTM. I have a few suggestions. Thanks for reviewing. > + /* > +* To avoid needing a TOAST table for pg_replication_origin, we restrict > +* replication origin names to 512 bytes. This should be more than enough > +*

Re: MergeJoin beats HashJoin in the case of multiple hash clauses

On Fri, Apr 11, 2025 at 5:06 AM Andres Freund wrote: > On 2025-04-11 00:47:19 +0200, Matthias van de Meent wrote: > > On Fri, 11 Apr 2025 at 00:27, Andres Freund wrote: > > > > > > Hi, > > > > > > On 2025-03-09 14:13:52 +0200, Alexander Korotkov wrote: > > > > I've revised commit message, comment

Re: type cache cleanup improvements

On Fri, Apr 11, 2025 at 11:32 PM Noah Misch wrote: > > On Tue, Oct 22, 2024 at 08:33:24PM +0300, Alexander Korotkov wrote: > > On Tue, Oct 22, 2024 at 6:10 PM Pavel Borisov > > wrote: > > > On Tue, 22 Oct 2024 at 11:34, Alexander Korotkov > > > wrote: > > >> I'm going to push this if no object

Re: n_ins_since_vacuum stats for aborted transactions

On Fri, Apr 11, 2025 at 12:33 PM Sami Imseih wrote: > > > I'm also thinking to reword n_tup_upd, something like: > > > > Total number of rows updated. Subsets of these updates are also tracked > in n_tup_hot_upd and n_tup_newpage_upd to facilitate performance monitoring. > > I think the current

Re: New committer: Jacob Champion

On Fri, Apr 11, 2025 at 01:26:04PM -0700, Jonathan S. Katz wrote: > Please join us in wishing Jacob much success and few reverts! Congratulations and welcome, Jacob! May your path lead to a peaceful buildfarm and few reverts. -- Michael signature.asc Description: PGP signature

Re: stats.sql fails during installcheck on mac

On Fri, Apr 11, 2025 at 10:44:59AM -0500, Sami Imseih wrote: > I actually originally had it this way, but for some reason > felt it would be better to be explicit about the methods we want to test > rather > than not test. I can't think of a very compelling reason to go either way, so > v2 > LGTM

Re: New committer: Jacob Champion

Congratulations Jacob! Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com On Fri, Apr 11, 2025 at 1:26 PM Jonathan S. Katz wrote: > The Core Team would like to extend our congratulations to Jacob > Champion, who has accepted an

Re: Fixing various typos in comments and docs

Thank you! I had completely forgotten about this, I appreciate that you dug this one out of the archives! > Existing spellcheckers for code usually have quite high rates of false > positives, so any automated tooling would have to avoid that to not become a > burden rather than a help. Personally

Re: n_ins_since_vacuum stats for aborted transactions

> WFM. Though is there a reason to avoid adding the "why" of the exception for > n_mod_since_analyze? I did think about that. I thought it will be understood that since this is a field that deals with ANALYZE, it will be understood that only committed changes matter here, and not worth adding mo

Re: stats.sql fails during installcheck on mac

> > what do you think of this? I think we should set fsync = on > > at least for the part of the test that proceeds the 2 checkpoints and > > set if back to off at the end of the tests for fsync stats. It is concerning > > the tests for the fsync stats are not being exercised in > > the buildfarm.

Re: Add missing PGDLLIMPORT markings

On 09.04.25 12:02, Peter Eisentraut wrote: I ran src/tools/mark_pgdllimport.pl and it detected a few new global variables with missing markings.  See attached patch.  Please point out if any of these should not be marked or if they are special cases in some other way.  I'm Cc'ing various people

Re: Improve a few appendStringInfo calls new to v18

On 10.04.25 05:51, David Rowley wrote: Looks like v18 has grown a few appendStringInfo misusages, e.g. using appendStringInfo() when no formatting is needed or just using format "%s" instead of using appendStringInfoString(). Would it be useful to augment appendStringInfo() something like this:

Re: n_ins_since_vacuum stats for aborted transactions

On Fri, Apr 11, 2025 at 5:19 PM Sami Imseih wrote: > > WFM. Though is there a reason to avoid adding the "why" of the > exception for n_mod_since_analyze? > > I did think about that. I thought it will be understood that since > this is a field that deals with ANALYZE, > it will be understood tha

Re: New committer: Jacob Champion

Congrats, Jacob. Thanks && Regards, Srinath Reddy Sadipiralla, EDB: https://www.enterprisedb.com

Re: New committer: Jacob Champion

On Saturday, 12 April 2025, Jonathan S. Katz wrote: > The Core Team would like to extend our congratulations to Jacob Champion, > who has accepted an invitation to become our newest PostgreSQL committer. > > Please join us in wishing Jacob much success and few reverts! > Many congratulations, Ja

Re: stats.sql fails during installcheck on mac

On Fri, Apr 11, 2025 at 07:37:49PM -0500, Sami Imseih wrote: > Yes, there should be some tests running for these stats, > so if it's possible to enable fsync on one or a few animals, that > will be better than nothing. I have just done that on batta that only tests HEAD, that's a start. -- Michael

Small patch fixing a query correctness issue in Gin with operator classes implementing Consistent functions

Hi All, Please find a small patch to fix an existing bug in the GIN index that impacts correctness of query results for operator classes that use a consistentFunction and do not specify a triConsistent function. This patch is against the master and fixes an issue not in any release branches. Plea

Re: New committer: Jacob Champion

On Fri, Apr 11, 2025 at 4:26 PM Jonathan S. Katz wrote: > Please join us in wishing Jacob much success and few reverts! Well done, Jacob. -- Peter Geoghegan

Re: TOAST versus toast

On Sun, Mar 16, 2025 at 8:33 PM Peter Smith wrote: > Thanks for your suggestions. At this point option (1) is looking most > attractive. Probably, I will just withdraw the CF entry soon unless > there is some new interest. Just chipping away fixing a few places > isn't going to achieve the consis