Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp

On Thu, Nov 27, 2025 at 6:48 AM Amit Langote wrote: > > On Thu, Nov 27, 2025 at 7:59 AM Michael Paquier wrote: > > On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote: > > > On Wed, Nov 26, 2025 at 5:41 PM Amit Langote > > > wrote: > > >> [] > > > > It seems to me that it is important

Re: [Patch] Windows relation extension failure at 2GB and 4GB

On 11/14/2025 12:44 AM, Michael Paquier wrote: > On Thu, Nov 13, 2025 at 10:58:54AM -0600, Bryan Green wrote: >> On 11/12/2025 10:05 PM, Michael Paquier wrote: Moving on to the I/O routine changes. There was a little bit of >>> noise in the diffs, like one more comment removed that should sti

Re: tuple radix sort

Hi John, I did an initial test before, but I didn’t read the code at the time. Today, I spent time reviewing 0001. Overall, I believe the implementation is solid. I just got a few comments/suggestions. > On Nov 26, 2025, at 21:11, John Naylor wrote: > > > For v5 I've also added CHECK_FOR_INT

Re: Move WAL/RMGR sequence code into its own file and header

On Thu, Nov 27, 2025 at 09:35:14AM +0200, Heikki Linnakangas wrote: > This doesn't really feel like an improvement to me, sequence.c is small > enough as is it is. If this helps with the other work you're doing though, > no objections. Yes, it does for the sequence AM patch where I'm splitting the

Re: Move WAL/RMGR sequence code into its own file and header

On 27/11/2025 06:29, Michael Paquier wrote: Hi all, Something that has been bugging me in the sequence code, while doing some recent work (cough), is the fact that it is possible to cleanly split the RMGR sequence code from the main sequence.c. Please find attached a patch doing that, cleaning

Re: IPC/MultixactCreation on the Standby server

On 27/11/2025 05:39, Chao Li wrote: 1 ``` + if (*offptr != offset) + { + /* should already be set to the correct value, or not at all */ + Assert(*offptr == 0); + *offptr = offset; + MultiXactOffsetCtl->shared->page_dirty[slot

Re: IPC/MultixactCreation on the Standby server

On 26/11/2025 23:15, Álvaro Herrera wrote: On 2025-11-26, Heikki Linnakangas wrote: What happens if you replay the WAL generated with old binary, without this patch, with new binary? It's not good: Maybe this needs a new record identifier, separating old wal from that generated by the new co

Re: Row pattern recognition

> On Nov 27, 2025, at 11:10, Tatsuo Ishii wrote: > > Hi Chao, > > Any comment on this? > >>> 13 - 0005 - nodeWindowAgg.c >>> ``` >>> static >>> int >>> do_pattern_match(char *pattern, char *encoded_str, int len) >>> { >>> static regex_t *regcache = NULL; >>> static regex_t preg; >>> static c

Re: pgsql: doc: Fix incorrect wording for --file in pg_dump

On Thu, Nov 27, 2025 at 06:48:56AM +0100, Erik Rijkers wrote: > In doc/src/sgml/ref/pg_dump.sgml, a tiny typo: > > "unless the directory exist and is empty." should be > "unless the directory exists and is empty." > > i.e., 'exists': because 'directory' is singular. Indeed, good catch. Daniel w

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

Hi Sawada-San. Some review comments for v30-0001. == doc/src/sgml/system-views.sgml 1. wal_level_insufficient means that the - primary doesn't have a sufficient to - perform logical decoding. It is set only for logical slots. + primary doesn

Re: pgsql: doc: Fix incorrect wording for --file in pg_dump

> On Nov 27, 2025, at 13:48, Erik Rijkers wrote: > > Op 11/7/25 om 15:27 schreef Daniel Gustafsson: >> Branch >> -- >> master >> Details >> --- >> https://git.postgresql.org/pg/commitdiff/07961ef86625be91e243f1dff8911cb1d70e443f >> Modified Files >> -- >> doc/src/sgml/ref/p

Re: pgsql: doc: Fix incorrect wording for --file in pg_dump

Op 11/7/25 om 15:27 schreef Daniel Gustafsson: Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/07961ef86625be91e243f1dff8911cb1d70e443f Modified Files -- doc/src/sgml/ref/pg_dump.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Hi, In do

Re: Support tid range scan in parallel?

On Thu, 27 Nov 2025 at 14:07, David Rowley wrote: > I went over this again today and only made a few whitespace > adjustments in the tests. I've now pushed the resulting patch. This seems to have caused issues on skink [1] under Valgrind. The problem seems to be that initscan() does not always i

Re: How can end users know the cause of LR slot sync delays?

On Thu, 27 Nov 2025 at 10:42, shveta malik wrote: > > On Thu, Nov 27, 2025 at 9:25 AM Shlok Kyal wrote: > > > > I have made some minor changes in documentation and comments. Attached > > the updated patch. > > > > 1) > NULL if >slot synchronization is successful. > > We shall add 'It is'

Re: Consistently use palloc_object() and palloc_array()

On Wed, Nov 26, 2025 at 10:25:12PM -0500, Tom Lane wrote: > Hmm ... I had the same doubts as Michael about whether this change > could possibly be worth the ensuing back-patching pain. But if > it leads to an improvement in type-safety, that'd be a reason to > take on the work. Yeah, that sounds

Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect

On Thu, Nov 27, 2025 at 11:46 AM Fujii Masao wrote: > > On Thu, Nov 27, 2025 at 2:37 AM Kirill Reshke wrote: > > Looking at v3 raises two questions for me. > > > > First is if we should have a doc notion of which variables ought to be > > set to what. > > Are you suggesting that we document which

Re: How can end users know the cause of LR slot sync delays?

On Thu, Nov 27, 2025 at 9:25 AM Shlok Kyal wrote: > > I have made some minor changes in documentation and comments. Attached > the updated patch. > 1) NULL if slot synchronization is successful. We shall add 'It is' to maintain continuity as the previous sentence has it. 2) Related to pr

Move WAL/RMGR sequence code into its own file and header

Hi all, Something that has been bugging me in the sequence code, while doing some recent work (cough), is the fact that it is possible to cleanly split the RMGR sequence code from the main sequence.c. Please find attached a patch doing that, cleaning a bit sequence.c by removing some of the WAL b

Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

On Thu, Nov 27, 2025 at 11:07:43AM +0800, 邱宇航 wrote: > Yes, and we got another two loops in pg_buffercache_evict functions, > and more loops in Drop/Flush relation/database buffers functions. Maybe > we can abstract them into a generic loop function and it takes a buffer > handler function pointer

Re: Partial hash index is not used for implied qual.

David Rowley writes: > On Thu, 27 Nov 2025 at 07:26, Tom Lane wrote: >> I checked the costing calculations and it's basically that >> genericcostestimate doesn't understand about hash buckets. > I assume you must mean using your "x % 100" case rather than Sergei's case. Right. >> ... tuples in

Re: How can end users know the cause of LR slot sync delays?

On Wed, 26 Nov 2025 at 15:21, Shlok Kyal wrote: > > On Wed, 26 Nov 2025 at 14:23, Zhijie Hou (Fujitsu) > wrote: > > > > On Wednesday, November 26, 2025 2:29 PM Shlok Kyal > > wrote: > > > I have also addressed the remaining comments and attached the updated > > > patch. > > > > Thanks for updat

Re: [PATCH] psql: add size-based sorting options (O/o) for tables and indexes

st 26. 11. 2025 v 14:01 odesílatel Pavel Stehule napsal: > Hi > > st 26. 11. 2025 v 13:44 odesílatel Euler Taveira > napsal: > >> On Wed, Nov 26, 2025, at 4:48 AM, M.Atıf Ceylan wrote: >> > Hello, >> > This patch adds two new meta-command modifiers for \dt(+) and \di(+): >> > >> > - O : sort

Re: IPC/MultixactCreation on the Standby server

Hi Heikki, I just reviewed this patch. As offset[x+1] anyway equals offset[x]+nmembers, pre-write offset[x+1] seems a very clever solution. I got a few questions/comments as below: > On Nov 27, 2025, at 04:59, Heikki Linnakangas wrote: > > Here's a new version of this. Notable changes: > > -

Re: Consistently use palloc_object() and palloc_array()

Thomas Munro writes: > This isn't a fully-baked thought, just a thought that occurred to me > while looking into that: If palloc_object(Int128AggState) were smart > enough to detect that alignof(T) > MAXALIGN and redirect to > palloc_aligned(sizeof(T), alignof(T), ...) at compile time, then > Int

Re: [PATCH] contrib: Add pg_datemath extension with datediff function

Hi st 26. 11. 2025 v 21:26 odesílatel Myles Lewis napsal: > Thank you Peter, Michael, and Pavel for the thoughtful feedback on my > initial submission. > > After considering your points, I've reframed this patch: > > Key Changes: > >1. Renamed from mssql_compat to pg_datemath - Removes any i

Re: transformJsonFuncExpr pathspec cache lookup failed

On Wed, Nov 26, 2025 at 8:57 PM Kirill Reshke wrote: > On Wed, 26 Nov 2025 at 10:32, Amit Langote wrote: > > On Wed, Nov 19, 2025 at 11:55 AM jian he > > wrote: > > > On Fri, Nov 7, 2025 at 2:26 PM Kirill Reshke > > > wrote: > > > > > > > > Hi! > > > > I tried your fix and this indeed fixes a

Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp

On Thu, Nov 27, 2025 at 10:28 AM Michael Paquier wrote: > On Thu, Nov 27, 2025 at 10:18:38AM +0900, Amit Langote wrote: > > I’m fine with updating all core callers to use the new *_safe(... Node > > *escontext) APIs all in one patch. However, we could consider keeping > > the existing *_opt_overfl

Re: Row pattern recognition

Hi Chao, Any comment on this? >> 13 - 0005 - nodeWindowAgg.c >> ``` >> static >> int >> do_pattern_match(char *pattern, char *encoded_str, int len) >> { >> static regex_t *regcache = NULL; >> static regex_t preg; >> static char patbuf[1024]; /* most recent 'pattern' is cached here */ >> ``` >> >

Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

> It is a slightly disappointing that the loops for > the buffers are duplicated, particularly for the relation vs the all > case. Yes, and we got another two loops in pg_buffercache_evict functions, and more loops in Drop/Flush relation/database buffers functions. Maybe we can abstract them into

Re: Partial hash index is not used for implied qual.

On Thu, 27 Nov 2025 at 07:26, Tom Lane wrote: > I checked the costing calculations and it's basically that > genericcostestimate doesn't understand about hash buckets. > For the partial index, it correctly estimates that we'll visit > all 10 of the tuples in the index, so it supposes that that > m

Re: Consistently use palloc_object() and palloc_array()

On Thu, Nov 27, 2025 at 11:10 AM David Geier wrote: > I've changed all code to use the "new" palloc_object(), palloc_array(), > palloc0_object(), palloc0_array, repalloc_array() and repalloc0_array() > macros. This makes the code more readable and more consistent. I wondered about this in the con

Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

> I do not think that will be a problem but I can change it if the > general consensus is towards this way. Also, if we change this for > pg_buffercache_mark_dirty_* functions, I think we need to apply the > same for the pg_buffercache_evict_* functions. After some testing, bgwriter/checkpointer d

Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect

On Thu, Nov 27, 2025 at 2:37 AM Kirill Reshke wrote: > Looking at v3 raises two questions for me. > > First is if we should have a doc notion of which variables ought to be > set to what. Are you suggesting that we document which GUC parameters should be set, and to what values, for logical repli

Re: Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations

Hello! > If you're interested in improving CIC and reducing its impact on > visibility horizons, you may be interested in reviewing Mihail's work > in [0]. Actually I reduced the scope of the patch to only single-heap-scan-STIR-based-CIC. But patch files are still available. I did it because it l

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

Hello! On Wed, Nov 26, 2025 at 7:34 PM Álvaro Herrera wrote: > We ran into one more problem with the new test, evidenced by timeouts by > buildfarm member prion. For CATCACHE_FORCE_RELEASE builds on two of the > tests, we get a few invalidations of the catalog snapshot ahead of what > we expect,

Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp

On Thu, Nov 27, 2025 at 10:18:38AM +0900, Amit Langote wrote: > I’m fine with updating all core callers to use the new *_safe(... Node > *escontext) APIs all in one patch. However, we could consider keeping > the existing *_opt_overflow() functions as thin wrappers over the new > ones, to avoid bre

Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp

On Thu, Nov 27, 2025 at 7:59 AM Michael Paquier wrote: > On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote: > > On Wed, Nov 26, 2025 at 5:41 PM Amit Langote > > wrote: > >> * The rename from *_opt_overflow to *_overflow_safe could be made a > >> separate patch (say 0002), so it can be dis

Re: Row pattern recognition

> I just finished reviewing 0007 and 0008. This patch set really demonstrates > the full lifecycle of adding a SQL feature, from changing the syntax in > gram.y all the way down to the executor, including tests and docs. I learned > a lot from it. Thanks! You are welcome! > 23 - 0007 > > As y

Re: Remaining dependency on setlocale()

> On Nov 26, 2025, at 09:50, Chao Li wrote: > > I will review the rest 3 commits tomorrow. 10 - 0009 ``` { if (isalpha((unsigned char) c)) { - c = toupper((unsigned char) c); + c = pg_ascii_toupper((unsigned char) c); ``` Just curious. As isaplha(

Re: Support tid range scan in parallel?

On Tue, 18 Nov 2025 at 14:51, David Rowley wrote: > I've attached v12, which adds a mention in the docs about Parallel TID > Range scans being supported. It also does very minor adjustments to > the comments. Again, I've kept Cary's v10 and the changes I've made > separate. Of course, I'd squash t

Re: Proposal: Conflict log history table for Logical Replication

Hi Dilip. Some review comments for v7-0001. == src/backend/replication/logical/conflict.c 1. + /* Insert conflict details to conflict log table. */ + if (conflictlogrel) + { + /* + * Prepare the conflict log tuple. If the error level is below + * ERROR, insert it immediately. Otherwise, defer

Re: [PATCH] Add native PIVOT syntax for SQL Server/Oracle compatibility

On Tue, Nov 25, 2025 at 09:21:49PM +0100, Peter Eisentraut wrote: > Your patch does not contain any documentation, so it's hard to tell what > this is supposed to do if you don't already know those other products. Can > you supply at least some informal documentation, and maybe some links to > rele

Re: Consistently use palloc_object() and palloc_array()

On Wed, Nov 26, 2025 at 11:09:31PM +0100, David Geier wrote: > I've changed all code to use the "new" palloc_object(), palloc_array(), > palloc0_object(), palloc0_array, repalloc_array() and repalloc0_array() > macros. This makes the code more readable and more consistent. > > The patch is pretty b

Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

On Mon, Nov 24, 2025 at 10:48:24AM +0300, Nazir Bilal Yavuz wrote: > Thanks for the heads up! It is rebased, I also added > 'CHECK_FOR_INTERRUPTS()' while looping over the 'NBuffers' regarding > the comment in the email [1]. > > [1] https://postgr.es/m/D5BB1D85-0F2A-419F-A7B1-426505525D3A%40gmail.

Re: Consistently use palloc_object() and palloc_array()

> On Nov 27, 2025, at 06:09, David Geier wrote: > > Hi hackers, > > I've changed all code to use the "new" palloc_object(), palloc_array(), > palloc0_object(), palloc0_array, repalloc_array() and repalloc0_array() > macros. This makes the code more readable and more consistent. > > The patch

Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp

On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote: > On Wed, Nov 26, 2025 at 5:41 PM Amit Langote wrote: >> * The rename from *_opt_overflow to *_overflow_safe could be made a >> separate patch (say 0002), so it can be discussed separately. For >> example, whether to keep the old *_opt_ove

Re: Some optimizations for COALESCE expressions during constant folding

On Thu, 27 Nov 2025 at 00:55, Richard Guo wrote: > > On Tue, Nov 25, 2025 at 10:16 PM David Rowley wrote: > > uhh, of course it is. That's what I did in [1] for Consts. Doing it > > this way means we'll not need to modify the constant folding code (or > > whichever other code wants to know when a

show size of DSAs and dshash tables in pg_dsm_registry_allocations

On Tue, Nov 25, 2025 at 07:13:03PM -0500, Robert Haas wrote: > In my ideal world, it would probably show partially-initialized entires > in some distinguishable way, like with a null size. I reevaluated this view, and I think we can do what you suggest here. Right now, we show NULL for DSAs and ds

Re: CREATE/ALTER PUBLICATION improvements for syntax synopsis

On Tue, Nov 25, 2025 at 10:47 PM Chao Li wrote: > > > > > On Nov 25, 2025, at 18:42, Fujii Masao wrote: > > > > On Fri, Nov 21, 2025 at 3:27 PM Chao Li wrote: > >> > >> > >> > >>> On Nov 21, 2025, at 05:08, Peter Smith wrote: > >>> > >>> I've reverted the ALTER 'publication_drop_object' part to

Re: Second RewriteQuery complains about first RewriteQuery in edge case

Dean Rasheed writes: > I think it is true that RewriteQuery() doesn't need to rewrite > individual CTEs multiple times. However, that doesn't mean that it > doesn't need to process the cteList at all below the top-level. The > problem is that rule actions may add additional CTEs to the list, > whi

Re: Have the planner convert COUNT(1) / COUNT(not_null_col) to COUNT(*)

On Wed, 26 Nov 2025 at 12:37, David Rowley wrote: > I'm not seeing any reason now not to go ahead with this now. Does > anyone else want to take a look at it before I start wielding the > sword of commitment on it? And pushed. Many thanks to Corey and Matheus for having a look at this. David

Re: Second RewriteQuery complains about first RewriteQuery in edge case

On Wed, 26 Nov 2025 at 20:29, Bernice Southey wrote: > > Bernice Southey wrote: > > I went through the history and it seemed to me the repeat rewrite was > > accidental because of the two ways this method can recurse. > I mean the repeat rewrite of the cteList was accidental, not the > repeat rew

Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent

On Tue, Nov 25, 2025 at 07:13:03PM -0500, Robert Haas wrote: > On Tue, Nov 25, 2025 at 4:16 PM Nathan Bossart > wrote: >> My tests seem happy, so I will plan on committing these patches tomorrow. >> The only difference in v4 is that pg_get_dsm_registry_allocations() will no >> longer show partial

Re: IPC/MultixactCreation on the Standby server

On 2025-11-26, Heikki Linnakangas wrote: > What happens if you replay the WAL generated with old binary, without > this patch, with new binary? It's not good: Maybe this needs a new record identifier, separating old wal from that generated by the new code? -- Álvaro Herrera

Re: IPC/MultixactCreation on the Standby server

Here's a new version of this. Notable changes: - I reverted the changes to ExtendMultiXactOffset(), so that it deals with wraparound and FirstMultiXactId the same way as before. The caller never passes FirstMultiXactId, but the changed comments and the assertion were confusing, so I felt it's

Re: postgres_fdw: Use COPY to speed up batch inserts

On Wed Nov 19, 2025 at 8:32 PM -03, Masahiko Sawada wrote: > I think one key point in the patch is whether or not it's okay to > switch using COPY based on the actual number of tuples inserted. While > it should be okay from the performance perspective, it might be an > issue that the remote query

Re: Second RewriteQuery complains about first RewriteQuery in edge case

Bernice Southey wrote: > I went through the history and it seemed to me the repeat rewrite was > accidental because of the two ways this method can recurse. I mean the repeat rewrite of the cteList was accidental, not the repeat rewrite of views. I couldn't think why a view would mean a cteList ne

Re: [PATCH] contrib: Add pg_datemath extension with datediff function

Thank you Peter, Michael, and Pavel for the thoughtful feedback on my initial submission.After considering your points, I've reframed this patch:Key Changes:Renamed from mssql_compat to pg_datemath - Removes any implication of tracking SQL Server compatibility, which was never the intent. This is a

Re: Second RewriteQuery complains about first RewriteQuery in edge case

Kirill Reshke wrote: > Added test are good, but two things: > 1) Why with.sql and not generated.sql ? This bug is "with" in combination with "generated identity" and "updatable view". The current fix targets "with", so that made me pick "with". It should move to "generated_stored" if the fix is id

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

On Tue, Nov 25, 2025 at 3:24 PM Peter Smith wrote: > > Hi Sawada-Sa, > > Some review comments for the patch v29-0001. Thank you for reviewing the patch! > > == > src/backend/access/transam/xact.c > > 1. > +int effective_wal_level = WAL_LEVEL_REPLICA; > > Should that be declared as WalLevel i

Re: oid2name : add objects file path

Hi David, I just looked at the commit fest entry and the bot says your patch needs a rebase. Can you do it? Thanks. Regards. On 08/10/2025 14:44, David Bidoc wrote: On Tue, Oct 7, 2025 at 11:47 AM Euler Taveira wrote: 1. The database query is wrong because it is considering that all datab

Re: System views for versions reporting

> On Wed, Nov 26, 2025 at 04:39:50PM +0100, Laurenz Albe wrote: > In the documentation of the "type" column, I suggest using > >Compile Time or Run Time > > (capitalization like in the view results), or even better > >Compile Time or Run Time Yeah, I've stored them both under "spelling"

Re: change default default_toast_compression to lz4?

On Wed, Nov 26, 2025, at 1:35 AM, Michael Paquier wrote: > On Fri, Nov 21, 2025 at 12:11:38PM +0100, Peter Eisentraut wrote: >> I suppose one issue is that lz4 support is not compiled-in by default, but >> in practice most users will have it. The default could be lz4 if lz4 >> support is built, ot

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

Hello, We ran into one more problem with the new test, evidenced by timeouts by buildfarm member prion. For CATCACHE_FORCE_RELEASE builds on two of the tests, we get a few invalidations of the catalog snapshot ahead of what we expect, and because we have an injection point to sleep there, those t

Re: should we have a fast-path planning for OLTP starjoins?

On 11/24/25 21:55, Robert Haas wrote: > On Sun, Nov 23, 2025 at 9:39 AM Tomas Vondra wrote: >>> 1. I do not think I believe the premise that the dimension tables >>> typically won't have restriction clauses. ISTM that a typical >>> query might be like >>> >>> select sum(o.total_price) from

Re: Partial hash index is not used for implied qual.

David Rowley writes: > On Tue, 25 Nov 2025 at 15:01, Tom Lane wrote: >> Actually, after thinking a bit longer, it'd be better to do something >> like the attached so that we don't keep redundant quals unless they'd >> *all* be excluded. > I think your 1st patch was more along the correct lines.

Re: [PATCH] Expose checkpoint timestamp and duration in pg_stat_checkpointer

Hi, On Wed, Nov 26, 2025 at 06:23:08PM +0100, Juan José Santamaría Flecha wrote: > El mié, 26 nov 2025, 11:14, Soumya S Murali > escribió: > There is a "Checkpoints" section in the pgbadger reports, and that's > probably the most widely used tool. That one parses the Postgres logs, so is unaffec

Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect

On Sat, 22 Nov 2025 at 17:14, Fujii Masao wrote: > > > Okay, thanks! > > I've updated the patch to use lengthof() as you suggested. > The revised version is attached. > > Regards, > > -- > Fujii Masao Looking at v3 raises two questions for me. First is if we should have a doc notion of which var

Re: Performance issues with parallelism and LIMIT

On 11/26/25 09:15, David Geier wrote: > On 19.11.2025 21:03, Tomas Vondra wrote: > >> Right, that's why I suggested to have a function the nodes would call in >> suitable places. >> > I like that idea, even though it would still not work while a node is > doing the crunching. That is after

Re: [PATCH] Expose checkpoint timestamp and duration in pg_stat_checkpointer

El mié, 26 nov 2025, 11:14, Soumya S Murali escribió: > On Mon, Nov 24, 2025 at 3:37 PM Álvaro Herrera > wrote: > > > In the past, I looked at a couple of monitoring dashboards offered by > > cloud vendors, searching for anything valuable in terms of checkpoints. > > What I saw was very disappoi

Re: Performance issues with parallelism and LIMIT

On 26.11.2025 09:15, David Geier wrote: > What we can do is use a global variable. That also makes checking the > flag a lot easier because we don't need to pass it around through > multiple abstraction layers. > > What needs to be taken care of though is to only bail from scans that > are actuall

Re: Second RewriteQuery complains about first RewriteQuery in edge case

Dean Rasheed writes: > The majority of RewriteQuery() is safe if it's called a second time on > the same query, because it fully expands all non-SELECT rules and > auto-updatable target views, so the second time round, it would do > nothing of that kind. However, evidently it's not safe to call >

Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect

On Tue, Nov 25, 2025 at 8:32 PM Fujii Masao wrote: > I found the following description in logical replication docs, which makes me > start thinking that the patch would need to be backpatched. I've prepared patches for the older branches as well and attached them. Regards, -- Fujii Masao From

Re: The pgperltidy diffs in HEAD

Daniel Gustafsson writes: >> On 26 Nov 2025, at 12:16, Daniel Gustafsson wrote: > >> I'll change that before committing and I'll also reword it to use >> the same error as pgindent > > More specifically, the attached is what I have staged for commit. LGTM > -- > Daniel Gustafsson - ilmari

Re: [buildfarm related] Machines gcc experimental failed test_lfind

On Wed, Nov 26, 2025 at 11:10:31AM -0500, Tom Lane wrote: > Anyway, this is exactly the sort of analysis that we shouldn't > be doing. Well, I wanted to be sure we weren't accidentally depending on undefined behavior, like what we fixed in commit 43da394. Something like that seemed within the rea

Re: The pgperltidy diffs in HEAD

> On 26 Nov 2025, at 12:16, Daniel Gustafsson wrote: > I'll change that before committing and I'll also reword it to use > the same error as pgindent More specifically, the attached is what I have staged for commit. -- Daniel Gustafsson v3-0001-Check-for-correct-version-of-perltidy.patch Des

Re: Fixes bug in strlower_libc_sb()

Hi, On Tue, Nov 25, 2025 at 01:50:42PM +0800, Chao Li wrote: > On Tue, Nov 25, 2025 at 11:03 AM Chao Li wrote: > > > Hi Hackers, > > > > While reviewing Jeff's patch [1], I found this bug in strlower_libc_sb(): > > > > ``` > > static size_t > > strlower_libc_sb(char *dest, size_t destsize, const

Re: [buildfarm related] Machines gcc experimental failed test_lfind

Nathan Bossart writes: > It looks like the failures are limited to AArch64, and commit f8f4afe did > change the code in question a bit. However, there are failures on older > PG versions where that commit was not applied, so the evidence does seem to > point to a compiler bug. The present failur

Re: [buildfarm related] Machines gcc experimental failed test_lfind

On Wed, Nov 26, 2025 at 10:51:12AM -0500, Tom Lane wrote: > If a problem is being observed only on animals with experimental > compilers, it's almost surely a compiler bug and not something > we should spend time on. In this case, the failure is in test > code that hasn't changed in several years,

Re: [Proposal] Adding TRIM_SPACE option to COPY

Hi all, Thank you for the feedback and for taking the time to review this patch. ## Performance Measurement Results > I also agree that this feature probably won't add noticeable overhead to > COPY when it isn't used, but it would still be good to measure > the performance impact of the patch. I

Re: [buildfarm related] Machines gcc experimental failed test_lfind

John Naylor writes: > On Wed, Nov 26, 2025 at 1:08 PM Hayato Kuroda (Fujitsu) > wrote: >> Also, what should we do for nightly-built compilers? Will we fix tests or >> codes for them? > We might ask ourselves how often these have resulted in > forward-looking fixes for our code, weighed against

Re: Remove unused struct fields

Committed. -- nathan

Re: POC: make mxidoff 64 bits

On 26/11/2025 17:23, Maxim Orlov wrote: On Tue, 25 Nov 2025 at 13:07, Heikki Linnakangas > wrote: GetOldMultiXactIdSingleMember() currently asserts that the offset is never zero, but it should try to do something sensible in that case instead of just failing. Correct me

Re: System views for versions reporting

On Wed, 2025-11-26 at 14:53 +0100, Dmitry Dolgov wrote: > > On Wed, Nov 26, 2025 at 02:28:06PM +0100, Laurenz Albe wrote: > > You didn't address any of my suggestions concerning the documentation, > > except that you moved the entry in "System Views" to the correct place. > > I did address the bui

Re: POC: make mxidoff 64 bits

On Tue, 25 Nov 2025 at 13:07, Heikki Linnakangas wrote: > > GetOldMultiXactIdSingleMember() currently asserts that the offset is > never zero, but it should try to do something sensible in that case > instead of just failing. > > Correct me if I'm wrong, but we added the assertion that offsets ar

Re: Second RewriteQuery complains about first RewriteQuery in edge case

On Wed, 26 Nov 2025 at 12:13, Kirill Reshke wrote: > > On Wed, 26 Nov 2025 at 13:34, Bernice Southey > wrote: > > > I get an odd error if a CTE inserts a GENERATED ALWAYS AS IDENTITY > > column, and then tries to modify an automatically updatable view. > > > > create table t(i int generated alwa

Re: Additional info for CREATE ROLE with REPLICATION

On Wednesday, November 26, 2025, Marcos Pegoraro wrote: > Em ter., 25 de nov. de 2025 às 23:22, Chao Li > escreveu: > >> > <0001-Master - Additional info for create role with REPLICATION.diff> >> > > ok, I understand that, but the REPLICATION paragraph says "A role having > the REPLICATION attri

Re: Remove unused struct fields

On Wed, Nov 26, 2025 at 02:54:48PM +, Bertrand Drouvot wrote: > Here are a few fields that are not used. - const char *username; /* username from startup packet */ + scram_state_enum state; /* username from startup packet */ - BlockNumber write_page;

Remove unused struct fields

Hi hackers, Here are a few fields that are not used. 1) username in scram_state: Added and used in 818fd4a67d61. Usage removed in f3049a603a7. 2) mask in PgAioWorkerSubmissionQueue: Added in and not used since 247ce06b883d. 3) write_page in SharedTuplestoreAccessor: Added in and not used sin

Re: macOS - Sequoia CI task is stuck on the Postgres Github CI

Hi, On 2025-11-26 15:38:37 +0100, Álvaro Herrera wrote: > > I noticed that the macOS – Sequoia CI task is stuck on the PostgreSQL > > GitHub CI [1], while the same task runs successfully on the CFBot [2]. > > On the CFBot, the worker jc-m2-1 is used, but the PostgreSQL GitHub CI > > does not show

Re: macOS - Sequoia CI task is stuck on the Postgres Github CI

On 2025-Nov-26, Nazir Bilal Yavuz wrote: > Hi, > > I noticed that the macOS – Sequoia CI task is stuck on the PostgreSQL > GitHub CI [1], while the same task runs successfully on the CFBot [2]. > On the CFBot, the worker jc-m2-1 is used, but the PostgreSQL GitHub CI > does not show a specific wor

Re: Serverside SNI support in libpq

> On 26 Nov 2025, at 10:14, Dewei Dai wrote: > > Hi Daniel, >I just reviewed the v11 patch and got a few comments: Thanks! > Typo: certficate -> certificate Fixed. > Typo: hand- shake ->handshake Fixed. > Typo: There need to be -> there needs to be AFAIK "need to be" is the correct

Re: macOS - Sequoia CI task is stuck on the Postgres Github CI

Hi, On 2025-11-26 16:44:00 +0300, Nazir Bilal Yavuz wrote: > I noticed that the macOS – Sequoia CI task is stuck on the PostgreSQL > GitHub CI [1], while the same task runs successfully on the CFBot [2]. > On the CFBot, the worker jc-m2-1 is used, but the PostgreSQL GitHub CI > does not show a spe

Re: Speed up COPY FROM text/CSV parsing using SIMD

On Wed, Nov 26, 2025 at 5:51 AM KAZAR Ayoub wrote: > Hello, > On Wed, Nov 19, 2025 at 10:01 PM Nathan Bossart > wrote: > >> On Tue, Nov 18, 2025 at 05:20:05PM +0300, Nazir Bilal Yavuz wrote: >> > Thanks, done. >> >> I took a look at the v3 patches. Here are my high-level thoughts: >> >> +/*

Re: [PATCH] Better Performance for PostgreSQL with large INSERTs

-Filip- út 7. 10. 2025 v 16:54 odesílatel Andres Freund napsal: > Hi, > > On 2025-10-07 15:03:29 +0200, Philipp Marek wrote: > > > Have you tried to verify that this doesn't cause performance > regressions > > > in > > > other workloads? pq_recvbuf() has this code: > > > > > ... > > > > > >

Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

Hi, On Mon, 24 Nov 2025 at 11:47, 邱宇航 wrote: > > > 2025年11月24日 15:50，Nazir Bilal Yavuz 写道： > > > > Could you please explain that a bit more? AFAIU, conditional locks are > > mainly used to escape from deadlock situations and we can not cause a > > deadlock here. Is it because using conditional l

Re: System views for versions reporting

> On Wed, Nov 26, 2025 at 02:28:06PM +0100, Laurenz Albe wrote: > You didn't address any of my suggestions concerning the documentation, > except that you moved the entry in "System Views" to the correct place. I did address the build failure and the order of entries, but looks like I've overlooke

Re: Question on PostgreSQL Table Partitioning – Performance of Queries That Do Not Use the Partition Key

Hi Atma, > Question on PostgreSQL Table Partitioning – Performance of Queries That Do > Not Use the Partition Key > > [...] pgsql-general@ might be a more appropriate mailing list for your question. Regarding the question per se, it would be helpful if you included the exact steps to reproduce t

macOS - Sequoia CI task is stuck on the Postgres Github CI

Hi, I noticed that the macOS – Sequoia CI task is stuck on the PostgreSQL GitHub CI [1], while the same task runs successfully on the CFBot [2]. On the CFBot, the worker jc-m2-1 is used, but the PostgreSQL GitHub CI does not show a specific worker name although it reports instance:PersistentWorker

Re: [PATCH] psql: add size-based sorting options (O/o) for tables and indexes

Hi, > This patch adds two new meta-command modifiers for \dt(+) and \di(+): > > -O : sort by total relation size descending > -o : sort by total relation size ascending > > This makes it easier to identify the largest tables and indexes > without writing custom SQL queries. > > Help message

  1   2   >