Re: C11 / VS 2019

On 03.06.25 10:01, Yura Sokolov wrote: Will it mean we can implement atomics in term of C11 atomics? Aside for VS 2019, which has no support for. (But VS 2022 already has.) So instead of numerous variants we could just differ VS2019 vs plain C11. I wrote: """ GCC details: The oldest gcc versio

Re: C11 / VS 2019

On 03.06.25 06:51, Michael Paquier wrote: Dropping VS 2015 and going up to VS 2019 brings other benefits, __VA_ARGS__ coming in mind. Yes, this was going to be my next step. As we're already talking about it, here is my proposed patch. For an explanation, the background is that MSVC has a "

Re: Add --system-identifier / -s option to pg_resetwal

On Wed, Jun 04, 2025 at 06:49:31AM +0200, Peter Eisentraut wrote: > Maybe we can stop eating up short options? A long option seems sufficient > for this. Agreed. > I don't see the need for interactive confirmation here. The user would have > explicitly chosen the option, so they get what they a

Re: Add --system-identifier / -s option to pg_resetwal

On 31.05.25 20:52, Nikolay Samokhvalov wrote: the attached patch adds a new -s / --system-identifier option to pg_resetwal that allows users to change the database cluster's system identifier; it can be useful when you need to make a restored cluster distinct from the original, or when cloning

Re: fix notes about password encryption in pg_authid docs

On Tue, Jun 03, 2025 at 01:01:58PM -0500, Nathan Bossart wrote: > Yup. Here is an updated patch. Looks fine to me. -- Michael signature.asc Description: PGP signature

Re: [PATCH] PGSERVICEFILE as part of a normal connection string

On Sun, Jun 01, 2025 at 09:36:08PM +0900, Ryo Kanbayashi wrote: > Strictly speaking, in a Windows environment, a path containing a > backslash is stored in the $td variable, so the value of the > $srvfile_valid variable, which contains that path, also needs to be > converted. > If conversion is not

Re: Improve explicit cursor handling in pg_stat_statements

On Tue, Jun 03, 2025 at 01:04:36PM -0500, Sami Imseih wrote: > v3 is what I'm thinking: In FetchStmt, introduce a new field called > explicit_direction (maybe there's a better name?), which is an int that > we can assign a value to in gram.c. The value will be 0 if no explicit > direction is used.

Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable

On 2025/06/03 19:45, Etsuro Fujita wrote: On Mon, Jun 2, 2025 at 12:33 PM Michael Paquier wrote: On Mon, Jun 02, 2025 at 12:03:50PM +0900, Fujii Masao wrote: I'm not sure this change should be considered a bug fix, since the current behavior of postgres_fdw with a local read-only transactio

Custom Glibc collation version strings under LOCPATH

Hi, One way to move to a newer glibc-based Linux distribution but keep the locales working the same* without keeping the associated zombie C code alive is to find the source system's collation definition source files, compile them with the localedef on the target system and point to the top-level

Enhance pg_createsubscriber to create required standby.

Hi All, Currently, pg_createsubscriber is designed to convert an existing physical replica into a logical subscriber. To use it, the user must manually set up a standby node beforehand, ensure that physical replication is active, and only then run pg_createsubscriber to perform the switchover to l

[19] Proposal: function markers to indicate collation/ctype sensitivity

=== Motivation === Right now, we are missing information about the dependencies between database objects and collation providers, which makes it very hard to migrate to a new collation provider version smoothly. Even assuming a user is willing to REINDEX potentially-affected indexes, they have no

Re: Foreign key validation failure in 18beta1

On Tue, Jun 3, 2025 at 12:14 PM Amul Sul wrote: > > > > I found a third approach that requires only a few changes. The key > idea is to determine the root referenced table and pass it to > QueueFKConstraintValidation(). We would then enqueue phase 3 > validation only if the constraint tuple’s conf

Re: Encapsulate io_uring process count calculation

On Tue, 03 Jun 2025 at 13:27, Michael Paquier wrote: > On Tue, Jun 03, 2025 at 12:16:21PM +0800, Japin Li wrote: >> I've replaced the hardcoded arithmetic expression for calculating TotalProcs >> within the pgaio_uring_shmem_init() with a call to the dedicated >> pgaio_uring_procs() function. >>

Re: Proposal: Limitations of palloc inside checkpointer

Hi all, Sorry—I forgot to Cc on my previous message. Resending here so they’re on the thread: On Wed, Jun 4, 2025 at 11:07 AM Xuneng Zhou wrote: > > Hi Alexander, > > Thanks again for the feedback! > > 1) Batch-processing CompactCheckpointerRequestQueue() and > AbsorbSyncRequests()? > > After s

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

HI I vote log_autovacuum_{vacuum|analyze}_min_duration. Then don't remove log_autovacuum_min_duration so easily! On Wed, Jun 4, 2025 at 7:16 AM Fujii Masao wrote: > > > On 2025/06/04 4:32, Sami Imseih wrote: > >> On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote: > >>> On Tue, Jun 03

Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

On Tue, May 20, 2025 at 9:54 PM Amit Kapila wrote: > > On Wed, May 21, 2025 at 12:45 AM Masahiko Sawada > wrote: > > > > On Mon, May 19, 2025 at 2:05 AM Amit Kapila wrote: > > > > > > On Sun, May 18, 2025 at 1:09 AM Masahiko Sawada > > > wrote: > > > > > > > > On Sat, May 10, 2025 at 7:08 AM

Re: Persist injection points across server restarts

On Tue, Jun 03, 2025 at 03:34:16PM -0400, Andres Freund wrote: > I'm somewhat doubtful this is is the right direction. Tests that require > injection points before consistency also can't wait for injection points using > the SQL interface or such, so most of the stuff has to be written in C > anywa

Re: MergeAppend could consider sorting cheapest child path

On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov wrote: > On 3/6/2025 16:05, Alexander Korotkov wrote: > > On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote: > >> Additionally, as I mentioned earlier, the primary reason for choosing > >> MergeAppend in the regression test was a slight total cost

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

On 2025/06/04 4:32, Sami Imseih wrote: On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote: On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote: I surely think adding log_autoanalyze_min_duration is simpler and shorter, but the reason I chose this GUC name is for consistenc

Re: Correcting freeze conflict horizon calculation

On Tue, Jun 3, 2025 at 2:00 PM Peter Geoghegan wrote: > > On Mon, Jun 2, 2025 at 4:00 PM Melanie Plageman > wrote: > > Perhaps I could keep track of the newest modified xid or some such > > thing that is the newer of the newest removed xmax and newest frozen > > xmin. > > BTW, I don't think that

Re: SpinLockAcquire and SpinLockRelease is broken on ARM/ARM64? (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

Hi, On 2025-06-02 21:20:33 +0300, Yura Sokolov wrote: > But still problem of spin lock contention is here. I still would like to see a reproducer for this. > So I propose to introduce another spin lock type capable for Exclusive and > Shared lock modes (i.e. Write/Read modes) and use it in this

Re: C11 / VS 2019

On Wed, Jun 4, 2025 at 2:02 AM Tom Lane wrote: > Yura Sokolov writes: > > Will it mean we can implement atomics in term of C11 atomics? > > Any such change would have to be supported by extensive performance > testing to verify that there's not a regression on any supported > platform. Yeah, it'

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Tue, 2025-06-03 at 11:27 -0400, Robert Haas wrote: > That's true, but search_path manipulation is still enough to cause > quite a few problems. +1. The only defense is to declare the function with "SET search_path", but until recently, that was a major performance penalty for cheap functions. A

Re: Correcting freeze conflict horizon calculation

On Tue, Jun 3, 2025 at 1:59 PM Peter Geoghegan wrote: > We do currently end up using OldestXmin-1 as our > snapshotConflictHorizon when this happens, but as I said in the other > email, I don't think that that's really required. Actually, that's not really true, either. That is, it is possible (t

Re: bt_index_parent_check and concurrently build indexes

Hello, Donghang! > One suggestion to this change is that we might need to update the amcheck doc > to reflect that > "This consists of a “dummy” CREATE INDEX CONCURRENTLY operation" rather than > "CREATE INDEX" operation. +1, done. Also fixed some typos in the commit message. Best regards, Mik

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

This latest patch set looks pretty good to me. -- nathan

Re: autoprewarm_dump_now

Hi, On 2025-06-03 13:17:43 -0400, Robert Haas wrote: > On Fri, May 30, 2025 at 6:07 AM Daria Shanina wrote: > > Some of our clients encountered a problem — they needed to allocate > > shared_buffers = 700 GB on a server with 1.5 TB RAM, and the error "invalid > > memory alloc request size 18350

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

> On 3 Jun 2025, at 10:53 PM, Nathan Bossart wrote: > > On Tue, Jun 03, 2025 at 10:39:25PM +0300, Florents Tselai wrote: >> Thanks for the detailed review Nathan > > Thanks for the updated patch! > > +if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo)) > +ereport(ERROR, (errmsg("pg

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

On Tue, Jun 03, 2025 at 10:39:25PM +0300, Florents Tselai wrote: > Thanks for the detailed review Nathan Thanks for the updated patch! +if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo)) +ereport(ERROR, (errmsg("pg_get_dsm_registry_allocations must be used in a SRF context"))); Init

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

Thanks for the detailed review Nathan > On 3 Jun 2025, at 4:52 PM, Nathan Bossart wrote: > > On Sat, Mar 15, 2025 at 10:41:15AM +0200, Florents Tselai wrote: >> Here's an updated v3 that fixes some white spaces v2 had-no other changes. > > Thanks for the patch. > >> I'm wondering though if it

Re: Persist injection points across server restarts

Hi, On 2025-06-03 13:13:06 +0900, Michael Paquier wrote: > On Mon, Jun 02, 2025 at 12:42:35PM -0700, Jeff Davis wrote: > > This seems like a fair amount of complexity for a single use case. > > Arguably, complexity around testing infrastructure is a lot less of a > > problem than other kinds of co

postmaster uses more CPU in 18 beta1 with io_method=io_uring

When measuring the time to create a connection, it is ~2.3X longer with io_method=io_uring then with io_method=sync (6.9ms vs 3ms), and the postmaster process uses ~3.5X more CPU to create connections. The reproduction case so far is my usage of the Insert Benchmark on a large server with 48 cores

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

> On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote: > > On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote: > >> I surely think adding log_autoanalyze_min_duration is simpler and > >> shorter, but the reason I chose this GUC name is for consistency with > >> other autovacuum p

Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

On Jun 3, 2025, at 15:02, David E. Wheeler wrote: > Patches attached, GitHub PR here: > > https://github.com/theory/postgres/pull/12 Found a little more unnecessary code to remove. Updated patches attached. Best, David v7-0001-Rename-jsonpath-method-arg-tokens.patch Description: Binary da

Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

Hackers, On May 26, 2025, at 18:00, David E. Wheeler wrote: > Yes, I think it would be best if the grammar was a bit stricter --- and > therefore more self-explanatory --- by making the args closer to what the > functions actually expect. I chatted with Florents and went ahead and simplified

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote: > On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote: >> I surely think adding log_autoanalyze_min_duration is simpler and >> shorter, but the reason I chose this GUC name is for consistency with >> other autovacuum parameters.

Re: Improve explicit cursor handling in pg_stat_statements

> Hmm, we could do that to differentiate the keyword ALL. I had a thought > earlier about differentiating the other keywords as well: FIRST, LAST, > BACKWARD, FORWARD, and ABSOLUTE. Initially, I thought it might > be a bit too much, but I do see the merit in this approach, as these are > syntactica

Re: Correcting freeze conflict horizon calculation

On Mon, Jun 2, 2025 at 4:00 PM Melanie Plageman wrote: > Perhaps I could keep track of the newest modified xid or some such > thing that is the newer of the newest removed xmax and newest frozen > xmin. BTW, I don't think that you have to worry about removing/freezing xmax when it comes to genera

Re: ABI Compliance Checker GSoC Project

On Jun 3, 2025, at 13:23, Mankirat Singh wrote: >> I don't think it's the >> job of the tool to determine that this ABI difference is okay. >> Ultimately that's for a human to determine, > > Yes, but it would be better if we could automate that thing to some > extent, along with the development

Re: ABI Compliance Checker GSoC Project

On 2025-Jun-03, Mankirat Singh wrote: > On Tue, 3 Jun 2025 at 20:49, Álvaro Herrera wrote: > > Please elaborate. Can you not write a suppression file that says > > "ignore offset changes for ios_in_progress in ReadStream", for example? > > I can do that, and that's what's causing the problem.

Re: fix notes about password encryption in pg_authid docs

On Tue, Jun 03, 2025 at 01:43:15PM +0900, Michael Paquier wrote: > You are missing one reference in doc/src/sgml/system-views.sgml for > pg_shadow.passwd, no? Yup. Here is an updated patch. -- nathan >From 2d41fa2cff14b548905e2dfdd98b992976137e61 Mon Sep 17 00:00:00 2001 From: Nathan Bossart D

Re: autoprewarm_dump_now

On Tue, Jun 3, 2025 at 1:24 PM Tom Lane wrote: > Robert Haas writes: > > I think the proposed patch should be committed and back-patched, after > > fixing it so that it's pgindent-clean and adding a comment. Does > > anyone have strong objection to that? > > Not here. I do wonder if we can't fi

Re: Persist injection points across server restarts

On Tue, 2025-06-03 at 13:13 +0900, Michael Paquier wrote: > In all the approaches I've considered, this one was the least worst > of > all based on the point that all the complexity is hidden in the test > module; there is no need to touch the backend code at all as long as > there is a way to retr

Re: autoprewarm_dump_now

On Fri, May 30, 2025 at 6:07 AM Daria Shanina wrote: > Some of our clients encountered a problem — they needed to allocate > shared_buffers = 700 GB on a server with 1.5 TB RAM, and the error "invalid > memory alloc request size 1835008000" occurred. That is, these are not mental > exercises.

Re: Avoid orphaned objects dependencies, take 3

On Mon, Jun 2, 2025 at 10:02 AM Bertrand Drouvot wrote: > So, we currently have 2 patterns: > > P1: permission checks on a referenced object is done before we call > recordMultipleDependencies() > P2: permission checks on a referenced object is done after we call > recordMultipleDependencies() >

Re: autoprewarm_dump_now

Robert Haas writes: > I think the proposed patch should be committed and back-patched, after > fixing it so that it's pgindent-clean and adding a comment. Does > anyone have strong objection to that? Not here. I do wonder if we can't find a more memory-efficient way, but I concur that any such

Re: ABI Compliance Checker GSoC Project

On Tue, 3 Jun 2025 at 20:49, Álvaro Herrera wrote: > > I don't think it's the > job of the tool to determine that this ABI difference is okay. > Ultimately that's for a human to determine, Yes, but it would be better if we could automate that thing to some extent, along with the development of t

Re: PG 18 release notes draft committed

On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote: > I have committd the first draft of the PG 18 release notes. When a commit changes the user that runs a function in existing queries, I think that almost always needs a release notes entry. It would follow that commit 01463e1 needs a

Re: pg_upgrade: warn about roles with md5 passwords

On Tue, Jun 03, 2025 at 09:43:59AM -0500, Nathan Bossart wrote: > On Tue, Jun 03, 2025 at 10:34:06AM -0400, Tom Lane wrote: >> If we really want to be in peoples' face about this, the thing >> to do is to print a warning every time they log in with an MD5 >> password. Also, to Michael's point, tha

Re: Replication slot is not able to sync up

On Fri, May 30, 2025 at 6:08 AM Zhijie Hou (Fujitsu) wrote: > To improve this workload scenario, we can modify pg_sync_replication_slots() > to > wait for the primary slot to advance to a suitable position before completing > synchronization and removing the temporary slot. This would allow the s

PoC: Compute a histogram of prune_xid to support autovacuum improvements

Hi all, in the scope of improving the autovacuum algorithm, this patch proposes to maintain a histogram of *smallest prunable xid per page* for each relation. It allows to estimate the number of pages that would be pruned by vacuum for a given cutoff. The *smallest prunable xid per page* is prune

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Tue, Jun 3, 2025 at 10:11 AM Bruce Momjian wrote: > I think the two cases are slightly different. Our existing system has > users running triggers on tables that don't own as themselves, so the > table owner has full control over what is in the triggers. If we were > to switch it so users run

Re: ABI Compliance Checker GSoC Project

On 2025-Jun-03, Mankirat Singh wrote: > 'struct ReadStream at read_stream.c:109:1' changed: > type size hasn't changed > 1 data member insertion: > 'int16 io_combine_limit', at offset 2 (in bytes) at read_stream.c:112:1 > there are data member changes: > 'int16 ios_in_progress' offse

Re: pg_upgrade: warn about roles with md5 passwords

On Tue, Jun 03, 2025 at 10:34:06AM -0400, Tom Lane wrote: > If we really want to be in peoples' face about this, the thing > to do is to print a warning every time they log in with an MD5 > password. Also, to Michael's point, that really would be exactly > the same place where the eventual "sorry,

Re: MergeAppend could consider sorting cheapest child path

On 3/6/2025 16:05, Alexander Korotkov wrote: On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote: Additionally, as I mentioned earlier, the primary reason for choosing MergeAppend in the regression test was a slight total cost difference that triggered the startup cost comparison. May you show

Re: pg_upgrade: warn about roles with md5 passwords

ISTM that warnings emitted by pg_upgrade will be seen by about 0.1% of users anyway, since packagers typically wrap scripts around that. If we really want to be in peoples' face about this, the thing to do is to print a warning every time they log in with an MD5 password. Also, to Michael's point

Re: ABI Compliance Checker GSoC Project

Thanks for the introduction :D On Tue, 3 Jun 2025 at 00:36, David E. Wheeler wrote: > Since the work naturally gets into what’s considered a public API and > what’s not, we feel that hackers is the best place to ask questions about > bits to include and exclude, as well as other questions relate

Re: pg_upgrade: warn about roles with md5 passwords

+1 for this, and +1 for doing this still in v18. On 03/06/2025 17:12, Nathan Bossart wrote: On Tue, Jun 03, 2025 at 01:38:49PM +0900, Michael Paquier wrote: I'm not sure that this is necessary. Only requiring one to use --retain sounds kind of enough to me. Yeah, maybe we should just leave i

Re: pg_upgrade: warn about roles with md5 passwords

On Tue, Jun 03, 2025 at 01:38:49PM +0900, Michael Paquier wrote: > I'm not sure that this is necessary. Only requiring one to use > --retain sounds kind of enough to me. Yeah, maybe we should just leave it alone for now. > Saying that, warning users if they have MD5 passwords is a good idea, > b

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Tue, Jun 3, 2025 at 08:58:58AM -0400, Robert Haas wrote: > On Mon, Jun 2, 2025 at 11:30 PM Tom Lane wrote: > > > That being said I would like to see it corrected everywhere. > > > > Yeah, one approach we could take here is to try to move the goalposts > > for this whole topic, understanding th

Re: MergeAppend could consider sorting cheapest child path

On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote: > On 3/6/2025 15:38, Alexander Korotkov wrote: > > On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote: > >> To establish a stable foundation for discussion, I conducted simple > >> tests - see, for example, a couple of queries in the attachm

Re: Incremental Sort Cost Estimation Instability

Hi, Andrei! On Wed, May 14, 2025 at 1:50 PM Andrei Lepikhov wrote: > On 9/12/24 16:57, Tomas Vondra wrote: > > On 9/12/24 12:12, David Rowley wrote: > >> On Thu, 12 Sept 2024 at 21:51, Andrei Lepikhov wrote: > >>> Initial problem causes wrong cost_sort estimation. Right now I think > >>> about p

Re: C11 / VS 2019

Yura Sokolov writes: > Will it mean we can implement atomics in term of C11 atomics? Any such change would have to be supported by extensive performance testing to verify that there's not a regression on any supported platform. Yeah, it'd be cool if we could rip out a lot of that code, but we ar

Re: MergeAppend could consider sorting cheapest child path

On 3/6/2025 15:38, Alexander Korotkov wrote: On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote: To establish a stable foundation for discussion, I conducted simple tests - see, for example, a couple of queries in the attachment. As I see it, Sort->Append works faster: in my test bench, it ta

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

On Sat, Mar 15, 2025 at 10:41:15AM +0200, Florents Tselai wrote: > Here's an updated v3 that fixes some white spaces v2 had-no other changes. Thanks for the patch. > I'm wondering though if it also makes sense to expose: > - backend_pid (who created the segment) > - is_pinned bool > - created_at

Re: MergeAppend could consider sorting cheapest child path

On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote: > On 2/6/2025 20:21, Alexander Korotkov wrote: > > I have the following question. I see patch changes some existing > > plans from Sort(Append(...)) to MergeAppend(Sort(), ..., Sort(...)) or > > even Materialize(MergeAppend(Sort(), ..., Sort(.

Re: MergeAppend could consider sorting cheapest child path

On 2/6/2025 20:21, Alexander Korotkov wrote: I have the following question. I see patch changes some existing plans from Sort(Append(...)) to MergeAppend(Sort(), ..., Sort(...)) or even Materialize(MergeAppend(Sort(), ..., Sort(...))). This should be some problem in cost_sort(). Otherwise, tha

Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

On Mon, Jun 2, 2025 at 2:53 PM Amit Kapila wrote: > > On Thu, May 29, 2025 at 5:29 PM Alexander Korotkov > wrote: > > > > On Tue, May 27, 2025 at 2:26 PM Amit Kapila wrote: > > > Yeah, we should be able to change ABI during beta, but I can't comment > > > on the idea of effective_restart_lsn wi

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Mon, 2 Jun 2025 at 23:30, Tom Lane wrote: > Isaac Morland writes: > > My fix would > > be for check constraints, triggers, and view definitions to run as the > > owner of the object in question (constraint, trigger, or view or > > materialized view), essentially using the same facility as us

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Mon, Jun 2, 2025 at 11:30 PM Tom Lane wrote: > > That being said I would like to see it corrected everywhere. > > Yeah, one approach we could take here is to try to move the goalposts > for this whole topic, understanding that that will mean incompatible > changes as well as some performance lo

Re: A modest proposal: make parser/rewriter/planner inputs read-only

On Thu, Apr 17, 2025 at 1:22 AM Tom Lane wrote: > Now, subquery_planner does have side effects on the PlannerGlobal > struct, but that's planner-local data, not an input to the planner. That reminded me of one place where we currently mutate planner input: inserting child RTEs into each subquery’

Add log_autovacuum_{vacuum|analyze}_min_duration

Hi hackers, I am proposing the introduction of two new GUC parameters, log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing log_autovacuum_min_duration. Motivation: Currently, log_autovacuum_min_duration controls the logging threshold for both autovacuum and autoanalyze activiti

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Some notes to the patch. ... Thanks for the notes! I'll try to make edits in the next few days. -- With best regards, Dmitry Koval Postgres Professional: http://postgrespro.com

Re: Logical Replication of sequences

On Thu, May 29, 2025 at 8:09 PM vignesh C wrote: > > These comments are handled in the attached v2025029 version patch. > 1. The current syntax to publish sequences is: CREATE PUBLICATION pub1 FOR ALL TABLES, ALL SEQUENCES; The other alternative could be: CREATE PUBLICATION pub1 FOR ALL TABLES,

Re: fix notes about password encryption in pg_authid docs

On Mon, Jun 02, 2025 at 09:21:39AM -0500, Nathan Bossart wrote: > On Mon, Jun 02, 2025 at 09:16:10AM -0500, Nathan Bossart wrote: >> I noticed that the docs for the pg_authid catalog still indicate that >> passwords might be stored "unencrypted," which hasn't been possible since >> commit eb61136.

Re: Improve explicit cursor handling in pg_stat_statements

> Should we offer something more consistent with DeallocateStmt, where > we have a boolean flag that would be set when ALL is specified, > included in the jumbling? This would mean two separate entries: one > for the constants and one for ALL. Hmm, we could do that to differentiate the keyword AL

Re: pg_upgrade: warn about roles with md5 passwords

On Mon, 2025-06-02 at 09:45 -0700, Jeff Davis wrote: > On Mon, 2025-06-02 at 10:32 -0500, Nathan Bossart wrote: > > Since MD5 passwords are slated to be marked as deprecated in v18, I figured > > it might be a good idea to add a check for roles with MD5 passwords to > > pg_upgrade.  I'm tempted to

Re: Suggestions for improving \conninfo output in v18

On Tue, Jun 3, 2025 at 4:28 AM Fujii Masao wrote: > On 2025/06/02 21:53, David G. Johnston wrote: > > On Sunday, June 1, 2025, Fujii Masao > > wrote: > > > > On 2025/06/02 14:24, David G. Johnston wrote: > > > > On Sunday, June 1, 2025, Fujii Masao

Re: Proposal: Limitations of palloc inside checkpointer

On Tue, Jun 3, 2025 at 1:16 PM Xuneng Zhou wrote: > Thanks a lot for reviewing! > > > I have few notes about that: > > 1) Should we make CompactCheckpointerRequestQueue() process the queue > > of checkpoint requests in smaller parts for the same reason we do this > > in AbsorbSyncRequests()? That

Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable

On Mon, Jun 2, 2025 at 12:33 PM Michael Paquier wrote: > On Mon, Jun 02, 2025 at 12:03:50PM +0900, Fujii Masao wrote: > > I'm not sure this change should be considered a bug fix, > > since the current behavior of postgres_fdw with a local read-only > > transaction isn't clearly documented. Some us

Re: Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait

Hi Fujii, Thanks a lot for reviewing! > > This update amends the previous patch by replacing the global > > XactLockTableWait_us with a local wait_us variable inside > > XactLockTableWait. Now each call resets its backoff to 1 ms, doubling > > up to 1 s when oper == XLTW_None. This eliminates shar

Re: [PATCH] Allow parallelism for plpgsql return expression after commit 556f7b7

On Tue, May 20, 2025 at 1:45 PM DIPESH DHAMELIYA wrote: > > > On Tue, May 20, 2025 at 11:57 AM Dilip Kumar wrote: > > > > I don't think we can remove the 'maxtuples' parameter from > > exec_run_select(). In this particular case, the query itself is > > returning a single tuple, so we are good. S

Re: Proposal: Limitations of palloc inside checkpointer

Hi Alexander, Thanks a lot for reviewing! > I have few notes about that: > 1) Should we make CompactCheckpointerRequestQueue() process the queue > of checkpoint requests in smaller parts for the same reason we do this > in AbsorbSyncRequests()? That would require significant redesign of > the alg

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi, Dmitry! On Tue, May 20, 2025 at 1:36 AM Dmitry Koval wrote: > Changes in patches: > > 1) Added usage of SECURITY_RESTRICTED_OPERATION for SPLIT/MERGE > PARTITION(S) commands. > > 2) For SPLIT PARTITION command: new partitions will have the same owner > as the parent. > > 3) For MERGE PARTITIO

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Thu, May 22, 2025 at 11:57 AM Dmitry Koval wrote: > > superuser can bypass all permission checks. > > superuser can attach any table to the partitioned table as he wants. > > That's right. > Using SUPERUSER may be a rare situation, but it needs to be processed. I suggest that owner of new part

Re: Improve tab completion for COPY

On Thu, 8 May 2025 21:39:10 +0900 torikoshia wrote: > Thanks for your comments! > > On 2025-05-08 08:53, Yugo Nagata wrote: > > On Wed, 7 May 2025 14:36:35 -0700 > > Masahiko Sawada wrote: > > > >> On Wed, May 7, 2025 at 6:23 AM Yugo Nagata > >> wrote: > >> > > >> > On Wed, 7 May 2025 15:39:

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

Hi, On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote: > On Tue, Jun 3, 2025 at 4:42 PM Michael Banck wrote: > > On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote: > > > I am proposing the introduction of two new GUC parameters, > > > log_autovacuum_{vacuum|analyze}_min_durati

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

On Tue, 27 May 2025 09:00:01 +0300 Alexander Lakhin wrote: > Hello Yugo, > > 31.03.2025 14:22, Yugo Nagata wrote: > >> I found that multiple sessions concurrently execute CREATE OR REPLACE > >> FUNCTION > >> for a same function, the error "tuple concurrently updated" is raised. > >> This is >

Re: Suggestions for improving \conninfo output in v18

On 2025/06/02 21:53, David G. Johnston wrote: On Sunday, June 1, 2025, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote: On 2025/06/02 14:24, David G. Johnston wrote: On Sunday, June 1, 2025, Fujii Masao mailto:masao.fu...@oss.nttdata.com>

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

Thank you for the comment! On Tue, Jun 3, 2025 at 4:42 PM Michael Banck wrote: > > Hi, > > On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote: > > I am proposing the introduction of two new GUC parameters, > > log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing > > log_

Re: Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait

Hi all, This update amends the previous patch by replacing the global XactLockTableWait_us with a local wait_us variable inside XactLockTableWait. Now each call resets its backoff to 1 ms, doubling up to 1 s when oper == XLTW_None. This eliminates shared‐state bugs (where multiple backends or succ

Re: Improve explicit cursor handling in pg_stat_statements

On Mon, Jun 02, 2025 at 02:44:36PM -0500, Sami Imseih wrote: > Since the FETCH case is clear-cut, here is a patch that normalizes variable > fetch sizes in a FETCH command. At a minimum, we can apply this patch. > I’ve also added tests in pg_stat_statements utility.sql to demonstrate > how queryIds

Re: C11 / VS 2019

03.06.2025 07:51, Michael Paquier wrote: > On Mon, Jun 02, 2025 at 08:52:00AM -0500, Nathan Bossart wrote: >> On Mon, Jun 02, 2025 at 05:44:12AM +0200, Peter Eisentraut wrote: >>> Summary: >>> 1. require VS 2019 >>> 2. use C11 >>> >>> Thoughts? >> >> +1 > > +1 to move on for both of these. I got

macos exported symbols list not used for loadable modules

On macOS, when building with the make system, the exported symbols list (SHLIB_EXPORTS) is ignored. I don't think that is intentional. It was probably just forgotten, since that combination has never actually been used until now (for libpq-oauth). (Alternatively: Am I missing something? Is

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

Hi, On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote: > I am proposing the introduction of two new GUC parameters, > log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing > log_autovacuum_min_duration. How about adding log_autoanalyze_min_duration instead? That would st

Re: Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait

On 2025/06/03 13:35, Xuneng Zhou wrote: Hi all, This update amends the previous patch by replacing the global XactLockTableWait_us with a local wait_us variable inside XactLockTableWait. Now each call resets its backoff to 1 ms, doubling up to 1 s when oper == XLTW_None. This eliminates share