Re: Newly created replication slot may be invalidated by checkpoint

On Wed, Sep 17, 2025 at 4:19 PM Vitaly Davydov wrote: > > [1] 0001-Fix-invalidation-when-slot-is-created-during-checkpo.patch > - /* Calculate how many segments are kept by slots. */ - keep = slotsMinReqLSN; + /* + * Calculate how many segments are kept by slots. Keep the wal using + * the minima

Re: Improve pg_sync_replication_slots() to wait for primary to advance

On Tue, Sep 23, 2025 at 10:29 AM shveta malik wrote: > > On Mon, Sep 22, 2025 at 4:21 PM Ajin Cherian wrote: > > > > > > Created a patch v13 with these changes. > > > > Please find a few comments: > > 1) > + /* update the failure structure so that it can be freed on error */ > + fparams.slot_name

Re: SQL:2023 JSON simplified accessor support

The new approach of introducing “transform_partial” looks like a better solution, which leads to less code change to hstore_subs and arraysubs. However, when I tested the v21, I encountered errors when combine composite type, array and jsonb together. Prepare test data: ``` drop table if exists

Re: [PATCH] Add tests for Bitmapset

Michael Paquier writes: > The result I had was good enough, so applied. The CI was OK, the > buildfarm may have a different opinion. This patch seems to be rather full of arbitrary casts to or from Datum, which is no longer okay. You need to be using the appropriate conversion macros, such as P

Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object

On Mon, Sep 15, 2025 at 8:40 PM jian he wrote: > > Summary of attached v4: > v4-0001: Handles ALTER TABLE DROP COLUMN when whole-row Vars are > referenced in check constraints and indexes. > > v4-0002: Handles ALTER TABLE ALTER COLUMN SET DATA TYPE when whole-row > Vars are referenced in check con

Re: GNU/Hurd portability patches

Hello Michael, Thank you for paying attention to this! Maybe I was wrong and we can at least categorize these failures -- I hope their number is finite, but my point was that it's hardly possible to use the information, that fruitcrow gives us, to improve Postgres. 22.09.2025 10:22, Michael Ban

Re: [PATCH] Introduce unified support for composite GUC options

út 23. 9. 2025 v 6:33 odesílatel Чумак Антон napsal: > >when you use json, then what is the benefit from your patch? > > json is just a syntax. This is only part of the patch. The main feature is > that we can directly, in a standard way, without the efforts of developers, > translate composite v

Re: [PATCH] Introduce unified support for composite GUC options

>when you use json, then what is the benefit from your patch? json is just a syntax. This is only part of the patch. The main feature is that we can directly, in a standard way, without the efforts of developers, translate composite values from user interfaces like psql or postgresql.conf into

Re: issue with synchronized_standby_slots

On Fri, Sep 12, 2025 at 2:34 PM Shlok Kyal wrote: > > I have attached the updated v4 patch > +# Cannot be set synchronized_standby_slots to a reserved slot name +($result, $stdout, $stderr) = $primary->psql('postgres', + "ALTER SYSTEM SET synchronized_standby_slots='pg_conflict_detection'"); +ok(

Re: Invalid primary_slot_name triggers warnings in all processes on reload

On Fri, Sep 19, 2025 at 12:00 PM Fujii Masao wrote: > > So I agree it's safer to free them explicitly. In the attached updated patch, > ReplicationSlotValidateName() now pfrees err_msg and err_hint when needed. > +error: + if (elevel == 0) + { + GUC_check_errdetail("%s", err_msg); + if (err_hint

Re: [PATCH] Introduce unified support for composite GUC options

út 23. 9. 2025 v 5:50 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > Using GUC as session variables is a workaround because there is nothing > > better. But it is not good solution > > Agreed, but we don't yet have a better one ... > but better GUC will not be good session variables

Re: [PATCH] Introduce unified support for composite GUC options

út 23. 9. 2025 v 5:38 odesílatel Чумак Антон napsal: > Sorry, I replied to the email without the hackers tag, so some of our > correspondence was not saved on hackers. Therefore, I will quote my answer > and Pavel's questions and remarks below. > > > >>Thank you for your question! > >>Composite p

Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

I've noticed that two GROUP BY ROLLUP queries behave differently in v17 compared to master and REL_18_STABLE. The issue can be reproduced by following SQL: ``` SQL CREATE TABLE t(id int); INSERT INTO t SELECT generate_series(1, 3); -- Query 1 SELECT DISTINCT 'XXX' FROM t GROUP BY ROLLUP (id, 1);

Re: [PATCH] Introduce unified support for composite GUC options

Sorry, I replied to the email without the hackers tag, so some of our correspondence was not saved on hackers. Therefore, I will quote my answer and Pavel's questions and remarks below. >>Thank you for your question! >>Composite parameters in a configuration system are needed to describe comple

Re: Trivial fix for comment of function table_tuple_lock

> On Sep 23, 2025, at 08:45, Fujii Masao wrote: > > > I noticed the commit message in the patch lists you as "Author: Chao > Li mailto:[email protected]>>", > but in this discussion you've been using "[email protected] > ", > which also seems to be the addres

Re: Trivial fix for comment of function table_tuple_lock

On Tue, Sep 23, 2025 at 7:44 AM Chao Li wrote: > > > On Mon, Sep 22, 2025 at 11:41 PM Fujii Masao wrote: >> >> >> I noticed a few other issues. Wouldn’t it be better to fix these together? >> >> * changingPart is listed as an output parameter for table_tuple_delete(), >> but it looks like an

Re: Fix wrong filename in header comment of gin_tuple.h

On Tue, 23 Sept 2025 at 10:21, Chao Li wrote: > My script just scan all .c and .h files and extract one-line filename and > file path from header comments. If they don’t equal to either pure filename > or file path relative to repo root, then capture it. And rowsecurity.c was > the only capture

Re: Fix overflow of nbatch

On Tue, 23 Sept 2025 at 09:31, Tomas Vondra wrote: > On 9/22/25 22:45, David Rowley wrote: > > I think a1b4f289b mistakenly thought that there'd be size_t arithmetic > > in the following two lines because the final result is a size_t: > > > > size_t current_space = hash_table_bytes + (2 * nbatch *

Re: Fix overflow of nbatch

> On Sep 22, 2025, at 21:20, Vaibhav Jain wrote: > > Hi Everyone, > > With a1b4f28, to compute current_space, nbatch is being multiplied > by BLCKSZ. nbatch is int and when multiplied with BLCKSZ, it can > easily overflow the int limit.To keep the calculation safe for > current_space, convert

Re: Fix overflow of nbatch

On Tue, 23 Sept 2025 at 11:21, Chao Li wrote: > I guess that because earlier in the function, nbatch is always clamped with: > > nbatch = pg_nextpower2_32(Max(2, minbatch)); I don't follow which part of that line could be constituted as clamping. Maybe you've confused Max with Min? David

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

On Sun, Sep 21, 2025 at 8:40 PM Ashutosh Bapat wrote: > > On Fri, Sep 19, 2025 at 10:49 PM Masahiko Sawada > wrote: > > > > On Fri, Sep 19, 2025 at 7:45 AM Ashutosh Bapat > > wrote: > > > > > > On Fri, Sep 12, 2025 at 2:26 PM Ashutosh Bapat > > > wrote: > > > > > > > > On Fri, Sep 12, 2025 at

a couple of small patches for simd.h

0001 essentially reverts commit c6a43c2, and instead fixes the problem (MSVC dislikes casts to the same type) by omitting the cast in the problematic line in pg_lfind32(). While working on optimizing hex_encode() and hex_decode() [0], I noticed that implicit conversions sufficed. 0002 optimizes v

Re: [PATCH] Introduce unified support for composite GUC options

On Monday, September 22, 2025, Tom Lane wrote: > =?utf-8?q?=D0=A7=D1=83=D0=BC=D0=B0=D0=BA_=D0=90=D0=BD=D1=82=D0=BE=D0=BD?= > writes: > > This patch adds a unified mechanism for declaring and using composite > configuration options in GUC, eliminating the need to write a custom parser > for each

Re: Thoughts on NBASE=100000000

On Sun, 21 Sept 2025 at 17:09, Joel Jacobson wrote: > Is there a greater-than-zero chance we could want to modernizing numeric > for 64-bit hardware, even if it would require a change to its internals? I can't quite speak to the proposal for differentiating the two different on-disk formats, but

Re: Fix overflow of nbatch

On Tue, 23 Sept 2025 at 01:57, Vaibhav Jain wrote: > With a1b4f28, to compute current_space, nbatch is being multiplied > by BLCKSZ. nbatch is int and when multiplied with BLCKSZ, it can > easily overflow the int limit.To keep the calculation safe for > current_space, convert nbatch to size_t. Th

Re: Updating IPC::Run in CI?

Hi, On 2025-09-22 13:17:09 -0700, Jacob Champion wrote: > On Thu, Sep 18, 2025 at 12:35 PM Jacob Champion > wrote: > > Right. On the Debian side, looks like bookworm is stuck on 20220807.0 > > -- and updating to trixie won't help us either; that just gets us up > > to 20231003.0. > > To more exp

Re: Updating IPC::Run in CI?

On Thu, Sep 18, 2025 at 12:35 PM Jacob Champion wrote: > Right. On the Debian side, looks like bookworm is stuck on 20220807.0 > -- and updating to trixie won't help us either; that just gets us up > to 20231003.0. To more explicitly defend my position here: I can request updates from package mai

Re: [PATCH] Hex-coding optimizations using SVE on ARM.

On Fri, Sep 12, 2025 at 04:30:21PM -0500, Nathan Bossart wrote: > I've attached a new version of the patch with a simd.h version of > hex_decode(). Here are the numbers: I was able to improve the hex_decode() implementation a bit. arm buf | HEAD | patch | % diff ---+-

Re: Fix wrong filename in header comment of gin_tuple.h

On Mon, 22 Sept 2025 at 14:46, Chao Li wrote: > diff --git a/src/backend/rewrite/rowsecurity.c > b/src/backend/rewrite/rowsecurity.c > - * rewrite/rowsecurity.c > + * rowsecurity.c > + * > + * IDENTIFICATION > + *src/backend/rewrite/rowsecurity.c I don't what's incorrect with these as I'm

Re: RFC: extensible planner state

Robert Haas writes: > I think that was rebased over a patch I inadvertently committed to my > local master branch. Trying again. I looked through the v5 patchset. 0001: The allocation logic in Set*ExtensionState fails to guarantee that it's made the array(s) big enough to hold the passed ID, whi

Re: [PATCH] Introduce unified support for composite GUC options

=?utf-8?q?=D0=A7=D1=83=D0=BC=D0=B0=D0=BA_=D0=90=D0=BD=D1=82=D0=BE=D0=BD?= writes: > This patch adds a unified mechanism for declaring and using composite > configuration options in GUC, eliminating the need to write a custom parser > for each new complex data type.  New syntax for end user is j

Re: [PATCH] Introduce unified support for composite GUC options

po 22. 9. 2025 v 12:03 odesílatel Pavel Stehule napsal: > Hi > > po 22. 9. 2025 v 11:13 odesílatel Чумак Антон > napsal: > >> Thank you for your question! >> >> Composite parameters in a configuration system are needed to describe >> complex objects that have many interrelated parameters. Such e

Re: vacuumdb --analyze-only does not need to issue VACUUM (ONLY_DATABASE_STATS) ?

Hi, On Tue, Sep 16, 2025 at 5:36 PM Fujii Masao wrote: > Attached is the updated version of the patch. > Thanks for the updated version! LGTM. Kind regards, Mircea Cadariu

Re: Orphan page in _bt_split

> On 18 Sep 2025, at 7:28 AM, Michael Paquier wrote: > > On Tue, Sep 16, 2025 at 10:26:12AM +0900, Michael Paquier wrote: >> Saying that, this patch sounds like a good idea, making these code >> paths a bit more reliable for VACUUM, without paying the cost of an >> allocation. At least for HEA

Re: _CRT_glob stuff

On Fri, Sep 19, 2025 at 12:37 AM Peter Eisentraut wrote: > As to how it works, I'm not sure, but I suppose the linker somehow > arranges the initializations in the right order. Okay. I was a bit concerned that, if libpq pulled in this symbol via pgcommon, it might accidentally affect the client e

Re: vacuumdb --analyze-only does not need to issue VACUUM (ONLY_DATABASE_STATS) ?

On Mon, Sep 22, 2025 at 5:56 PM Mircea Cadariu wrote: > > Hi, > > On Tue, Sep 16, 2025 at 5:36 PM Fujii Masao wrote: >> >> Attached is the updated version of the patch. > > > Thanks for the updated version! LGTM. Thanks for the review! Unless there are any objections, I'll commit the patch. Reg

Fix overflow of nbatch

Hi Everyone, With a1b4f28, to compute current_space, nbatch is being multiplied by BLCKSZ. nbatch is int and when multiplied with BLCKSZ, it can easily overflow the int limit.To keep the calculation safe for current_space, convert nbatch to size_t. Please find a patch for the same. Thanks, Vaibh

Re: Trivial fix for comment of function table_tuple_lock

On Mon, Sep 22, 2025 at 2:54 PM Chao Li wrote: > > Hi Fujii-san, > > Thank you very much for taking care of this patch. > > I just updated the patch, see attached v2. In v2, I removed "tid" from the > comment of heap_lock_tuple(), and I found a couple of more occurrences of > "relation"=>"rel" i

Re: waiteventset.c XXX

Hi, On 2025-09-22 17:23:33 +0200, Álvaro Herrera wrote: > On 2025-Sep-18, Robert Haas wrote: > > > I submit that we should not have both a comment that says we must save > > and restore errno and code that doesn't. Maybe the comment is intended > > to imply that the caller should be doing such a

Re: Having postgresql.org link to cgit instead of gitweb

On 9/22/25 11:27 AM, Álvaro Herrera wrote: On 2025-Sep-22, Tom Lane wrote: My first thought about scheduling was "best not in the middle of the 18.0 release cycle". However, I don't know of any actual connection between gitweb/cgit and the release-making tasks. My second thought was "the poin

Re: waiteventset.c XXX

On 2025-Sep-18, Robert Haas wrote: > I submit that we should not have both a comment that says we must save > and restore errno and code that doesn't. Maybe the comment is intended > to imply that the caller should be doing such a save and restore, but > if so, then (a) that's not very clear from

Re: Having postgresql.org link to cgit instead of gitweb

On 2025-Sep-22, Tom Lane wrote: > My first thought about scheduling was "best not in the middle of the > 18.0 release cycle". However, I don't know of any actual connection > between gitweb/cgit and the release-making tasks. My second thought > was "the point here is to cut server load, and mayb

Re: Use WALReadFromBuffers in more places

On Sat, 2025-09-13 at 22:04 -0700, Bharath Rupireddy wrote: > Thanks for looking at this. Yes, the WAL writers can zero out flushed > buffers before WALReadFromBuffers gets to them. However, > WALReadFromBuffers was intentionally designed as an opportunistic > optimization - it's a "try this first,

Re: Having postgresql.org link to cgit instead of gitweb

On 9/19/25 4:54 PM, Jonathan S. Katz wrote: On 9/19/25 4:14 PM, Tom Lane wrote: "Jonathan S. Katz" writes: On a quick read, I believe this is easily settable in the cgit.css file by setting "tab-size" to "4". I did a quick test hacking this inline, and it worked. Cool, thanks for looking int

Re: Having postgresql.org link to cgit instead of gitweb

"Jonathan S. Katz" writes: > If the main concern is lack of diff - which cgit gives us back, and the > main objection is the tab-size patch (in previous email)[1], is there > any objection to moving forward with updating the URLs after this patch > is applied (which I can't do, as I don't have

Re: Trivial fix for comment of function table_tuple_lock

On Thu, Sep 11, 2025 at 2:40 PM Chao Li wrote: > > Hi Hackers, > > Just fixed an one-word error in comment. Please take a look. Thanks for the patch! LGTM. It looks like this happened because heapam_tuple_lock() and heap_lock_tuple() use the argument relation instead of rel, and the comments for

Re: [PATCH] Add tests for Bitmapset

On Sep 22 2025, at 3:57 am, Michael Paquier wrote: > On Fri, Sep 19, 2025 at 02:48:43PM -0400, Greg Burd wrote: >> I think I've incorporated your feedback which did indeed make the patch >> more readable/crisp and maintainable, thank you. >> >> coverage:HEADv7v8 >> lines..: 87

Re: We broke the defense against accessing other sessions' temp tables

On 9/22/25 10:14, Jim Jones wrote: > I also noticed that it is possible to LOCK a temp table from another > session (as superuser). It gets even stranger if the owner's session closes while there is a LOCK in a different session: == session 1 == $ /usr/local/postgres-dev/bin/psql postgres psq

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

On Mon, Sep 22, 2025 at 3:41 PM Shlok Kyal wrote: > > On Thu, 18 Sept 2025 at 13:17, Ashutosh Sharma wrote: > > > > > In addition to this, should anyone really need to query the skip > > reason if pg_replication_slots already shows that the slot is synced > > and not temporary? Ideally, users sho

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

On Fri Sep 19, 2025 at 12:13 PM -03, Arseniy Mukhin wrote: > I think it's impossible: before pushing anything to the queue we > acquire global lock in PreCommit_Notify(): > > LockSharedObject(DatabaseRelationId, InvalidOid, 0, AccessExclusiveLock); > > While we are holding the lock, no writers can

Re: AIX support

Hi, On 2025-09-22 11:09:53 +, AIX PG user wrote: > As for Meson builds, we did explore them earlier but encountered some > issues. Here are some issues/fixes we submitted to the meson community > https://github.com/mesonbuild/meson/issues/14334 For now, we would like to > focus initially on th

Re: Add memory_limit_hits to pg_stat_replication_slots

On Mon, Sep 22, 2025 at 4:35 PM Amit Kapila wrote: > > On Mon, Sep 22, 2025 at 1:41 PM Bertrand Drouvot > wrote: > > > > > > > > Since other statistics counter names are camel cases I think it's > > > better to follow that for the new counter. > > > > Makes sense, done with memoryLimitHits in v2

Re: Add memory_limit_hits to pg_stat_replication_slots

On Mon, Sep 22, 2025 at 1:41 PM Bertrand Drouvot wrote: > > > > > Since other statistics counter names are camel cases I think it's > > better to follow that for the new counter. > > Makes sense, done with memoryLimitHits in v2 attached (that's the only change > as compared with v1). > The memory

Re: Improve pg_sync_replication_slots() to wait for primary to advance

On Tue, Sep 16, 2025 at 4:23 PM shveta malik wrote: > > On Mon, Sep 15, 2025 at 6:17 PM Ajin Cherian wrote: > > > Thank You for the patch. Please find a few comments: > > 1) > + bool slot_persistence_pending = false; > > We can move this declaration outside of the loop. And I think we don't > nee

Re: [PATCH] Introduce unified support for composite GUC options

Hi po 22. 9. 2025 v 11:13 odesílatel Чумак Антон napsal: > Thank you for your question! > > Composite parameters in a configuration system are needed to describe > complex objects that have many interrelated parameters. Such examples > already exist in PostgreSQL: synchronous_standby_names or pr

Re: Logical Replication of sequences

6) I tried to test the patch. When sequences are more than the batch-size, but not enough to make a complete batch of max size, I get this error: LOG: logical replication sequence synchronization for subscription "sub1" - total unsynchronized: 118 LOG: logical replication sequence synchronizatio

Re: [PATCH] Introduce unified support for composite GUC options

Thank you for your question! Composite parameters in a configuration system are needed to describe complex objects that have many interrelated parameters. Such examples already exist in PostgreSQL: synchronous_standby_names or primary_conninfo. And with these parameters, there are some difficul

Re: Random pg_upgrade 004_subscription test failure on drongo

On Fri, 21 Mar 2025 at 18:54, vignesh C wrote: > > On Thu, 13 Mar 2025 at 18:10, Heikki Linnakangas wrote: > > > > > > Hmm, this problem isn't limited to this one pg_upgrade test, right? It > > could happen with any pg_upgrade invocation. And perhaps in a running > > server too, if a relfilenumbe

Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring

Hi Andres, On Sun, Sep 21, 2025 at 6:29 PM Andres Freund wrote: [..] > This seems too low-level for end user docs, while not explaining that the > impact is due to a high max_connections value, rather than a large number of > actually established connections. How about something like > > Note

Re: We broke the defense against accessing other sessions' temp tables

Hi On 9/21/25 21:39, David G. Johnston wrote: > On Sun, Sep 21, 2025 at 12:19 PM Jelte Fennema-Nio > wrote: > > On Sun, 21 Sept 2025 at 19:44, Tom Lane > wrote: > > Yeah, if it were 18-only we'd need a powwow about whether to bre

Re: Add memory_limit_hits to pg_stat_replication_slots

Hi, On Thu, Sep 11, 2025 at 03:24:54PM -0700, Masahiko Sawada wrote: > On Wed, Aug 27, 2025 at 12:26 AM Bertrand Drouvot > wrote: > > > > Looking forward to your feedback, > > Yes, Thanks for looking at it! > it's a quite different situation in two cases: spilling 100 > transactions in one Reo

Re: [PATCH] Add tests for Bitmapset

On Fri, Sep 19, 2025 at 02:48:43PM -0400, Greg Burd wrote: > I think I've incorporated your feedback which did indeed make the patch > more readable/crisp and maintainable, thank you. > > coverage:HEADv7v8 > lines..: 87.1 90.5 92.2 bitmap_match() had some duplicated tests. bms

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Sat, Sep 20, 2025 at 4:06 AM Dmitry Koval wrote: > > Hi, Jiah He! > > Thanks! > > >list_intersection seems not right, how can we be sure it deals with > >collation correctly? > > list_intersection function replaced by new partitions_lists_intersection > function. > hi, more about v60. + /*

Re: [PATCH] Introduce unified support for composite GUC options

Hi what is use case for this? Regards Pavel po 22. 9. 2025 v 8:55 odesílatel Чумак Антон napsal: > Hello hackers, > > The new version of the patch adds support for multi-line writing of > composite type values in the postgresql.conf file. Hidden fields have also > been added. Such fields may

Re: GNU/Hurd portability patches

On Mon, Sep 22, 2025 at 07:02:25AM +0900, Michael Paquier wrote: > On Sun, Sep 21, 2025 at 09:00:00AM +0300, Alexander Lakhin wrote: > > So it seems to me that Hurd is not mature enough yet to test Postgres. > > I'd say that it is likely not mature enough for production. In terms > of testing, th

Re: Documentation fix on pgbench \aset command

On Fri, Jun 27, 2025 at 10:37 AM Yugo Nagata wrote: > This will work if we assume that the query never returns the initial value. > I've attached a updated patch that fix the documentation as below: > > If a query returns no rows, no assignment is made. You can detect > this by initializing the