Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM

On Thu, 4 Dec 2025 at 21:33, Jelte Fennema-Nio wrote: > > On Thu, 4 Dec 2025 at 11:56, Kirill Reshke wrote: > > > One idea would be to disallow FROM PROGRAM when connecting over the > > network instead of a Unix socke > > > > How this would be protected from connecting to PostgreSQL over the > >

Re: pgsql: Add pg_atomic_unlocked_write_u64

On Thu, Dec 04, 2025 at 01:15:55PM -0500, Tom Lane wrote: > LGTM otherwise. +1 -- nathan

Re: apply_scanjoin_target_to_paths and partitionwise join

On Wed, Dec 3, 2025 at 9:53 PM Richard Guo wrote: > Fair point. I had envisioned a separate planning step involving a new > RelOptInfo, where we would re-add paths from the scan/join RelOptInfo > after applying the target, explicitly skipping Append paths for > partitioned tables. But I admit th

Re: pgsql: Add pg_atomic_unlocked_write_u64

Andres Freund writes: > How about: > /* > * pg_atomic_unlocked_write_u32 - unlocked write to atomic variable. > * > * Write to an atomic variable, without atomicity guarantees. I.e. it is not > * guaranteed that a concurent reader will not see a torn value, nor to grammar police: s/nor to/no

Re: bt_index_parent_check and concurrently build indexes

> Hi, I pushed this to 17 and up. Thanks! Thanks! I'll update my CIC patch then - now it is not required to have any other patch inbuilt.

Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE

I wrote: > Currently, configure tries "gnu_printf" then "__syslog__" then > "printf" to set PG_PRINTF_ATTRIBUTE. Of late, buildfarm member > fritillary has been issuing warnings like > ../../../../src/include/c.h:234:83: warning: 'syslog' is an unrecognized > format function type [-Wformat=] >

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

Hello! Seems like it may be easily fixed (see attached patch). Bwt, is it possible to somehow run the whole buildfarm over some branch? Such way it will be possible to fix such issues much earlier (some of them catched by github CI, but not all). Best regards, Mikhail. Subject: [PATCH] more test

Re: headerscheck ccache support

Hi, On 2025-12-04 11:52:07 +0100, Peter Eisentraut wrote: > What do people think about patch 0002, which runs headerscheck and > cpluspluscheck in parallel on ci? It should save several seconds of > wall-clock time for that task, and I don't see any drawbacks, unless you > want to retain the spec

Re: Adding REPACK [concurrently]

Em qui., 4 de dez. de 2025 às 12:43, Álvaro Herrera escreveu: > If you only have a small number of pages that have this problem, then > you don't actually need to do anything -- the pages will be marked free > by regular vacuuming, and future inserts or updates can make use of > those pages. It'

Re: bt_index_parent_check and concurrently build indexes

Hi, I pushed this to 17 and up. Thanks! -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Selbst das größte Genie würde nicht weit kommen, wenn es alles seinem eigenen Innern verdanken wollte." (Johann Wolfgang von Goethe) Ni aún el genio más grande

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

The "partitioned" test failed recently also on flaviventris and adder: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2025-12-04%2017%3A28%3A20 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=adder&dt=2025-12-03%2009%3A23%3A08 https://buildfarm.postgresql.org/

Re: Proposal: Add a callback data parameter to GetNamedDSMSegment

> "caller after returning from GetNamedDSHash" <- do you mean > GetNamedDSMSegment ? Yes, that was a typo. > wouldn't the above be sufficient to create a DSM segment containing > a flexible array? Yes, it creates it, but can I initialize it properly in foo_init_state? How can I set the size memb

Re: pgsql: Add pg_atomic_unlocked_write_u64

Hi, On 2025-12-04 10:03:22 -0600, Nathan Bossart wrote: > On Thu, Dec 04, 2025 at 10:56:12AM -0500, Andres Freund wrote: > > The whole point of the _unlocked_ function is to use it for modifying an > > atomic that doesn't need to actually be atomic when modified by that > > function. The current u

Re: Adding REPACK [concurrently]

Hello Great to hear about this feature. You speak about table rewrite (suppose a whole-table rewrite). I would like to share idea of an alternative approach that also takes into account amount of WAL generated during the operation. Applicable to non-clustered case only. Let's consider a lar

Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM

On Thu, 4 Dec 2025 at 11:56, Kirill Reshke wrote: > > One idea would be to disallow FROM PROGRAM when connecting over the > network instead of a Unix socke > > How this would be protected from connecting to PostgreSQL over the > network and then executing dblink, making local (socket) connection?

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

On Thu, 4 Dec 2025 at 09:34, Antonin Houska wrote: > > Matthias van de Meent wrote: > > > On Mon, 1 Dec 2025 at 10:09, Antonin Houska wrote: > > > > > > Matthias van de Meent wrote: > > > > > > > I'm a bit worried, though, that LR may lose updates due to commit > > > > order differences between

Re: Proposal: Add a callback data parameter to GetNamedDSMSegment

> struct Foo { > LWLock lock; > size_t size; > Bar data[]; > }; > > * To create a few of these, I have to provide a lock name to the > callback, that's the "reusing the same callback" part again > * And then there's the question of initialization. Either I leave it > to the caller after

Re: Fix PrivateRefCount hash table key size

On Tue, Dec 02, 2025 at 02:43:25PM +, Bertrand Drouvot wrote: > - hash_ctl.keysize = sizeof(int32); > + hash_ctl.keysize = sizeof(Buffer); > hash_ctl.entrysize = sizeof(PrivateRefCountEntry); LGTM. Appears to be a minor oversight in commit 4b4b680c3d, but it's of no consequence

Re: Segmentation fault on proc exit after dshash_find_or_insert

Hi, On Fri, Dec 5, 2025 at 12:33 AM Andres Freund wrote: > On 2025-12-04 11:06:20 +0900, Amit Langote wrote: > > On Thu, Dec 4, 2025 at 12:33 AM Andres Freund wrote: > > > I don't agree. You *cannot* rely on lwlocks working after an error before > > > you > > > have called LWLockReleaseAll(). I

Re: pgsql: Add pg_atomic_unlocked_write_u64

On Thu, Dec 04, 2025 at 10:56:12AM -0500, Andres Freund wrote: > The whole point of the _unlocked_ function is to use it for modifying an > atomic that doesn't need to actually be atomic when modified by that > function. The current use-case for it is to to modify BufferDesc->state for > temporary

Re: pgsql: Add pg_atomic_unlocked_write_u64

Hi, On 2025-12-04 09:51:10 -0600, Nathan Bossart wrote: > On Wed, Dec 03, 2025 at 11:40:47PM +, Andres Freund wrote: > > Add pg_atomic_unlocked_write_u64 > > > > The 64bit equivalent of pg_atomic_unlocked_write_u32(), to be used in an > > upcoming patch converting BufferDesc.state into a 64bi

Re: Batching in executor

On Wed, Oct 29, 2025 at 3:37 PM Amit Langote wrote: > On Tue, Oct 28, 2025 at 10:40 PM Amit Langote wrote: > > That would be nice to see if you have the time, but maybe after I post > > a new version. > > I’ve created a CF entry marked WoA for this in the next CF under the > title “Batching in ex

Re: pgsql: Add pg_atomic_unlocked_write_u64

On Wed, Dec 03, 2025 at 11:40:47PM +, Andres Freund wrote: > Add pg_atomic_unlocked_write_u64 > > The 64bit equivalent of pg_atomic_unlocked_write_u32(), to be used in an > upcoming patch converting BufferDesc.state into a 64bit atomic. I noticed that this new function was defined as

Re: Adding REPACK [concurrently]

Hello David, Thanks for your interest in this. On 2025-Dec-04, David Klika wrote: > Let's consider a large table where 80% blocks are fine (filled enough by > live tuples). The table could be scanned from the beginning (left side) to > identify "not enough filled" blocks and also from the end (r

Re: POC: make mxidoff 64 bits

On Thu, 4 Dec 2025 at 13:39, Heikki Linnakangas wrote: > However, that doesn't hold for pg_upgrade. pg_upgrade will try to read > all the multixids. So we need to make the multixact reading code > tolerant of the situations that could be present after a crash. I think > the right philosophy here

Re: Segmentation fault on proc exit after dshash_find_or_insert

Hi, On 2025-12-04 11:06:20 +0900, Amit Langote wrote: > On Thu, Dec 4, 2025 at 12:33 AM Andres Freund wrote: > > I don't agree. You *cannot* rely on lwlocks working after an error before > > you > > have called LWLockReleaseAll(). I.e. currently *any* use of lwlocks in > > before_shmem_exit is u

Re: Use func(void) for functions with no parameters

Bertrand Drouvot writes: > On Wed, Dec 03, 2025 at 11:32:10PM -0500, Tom Lane wrote: >> I looked into enabling -Wstrict-prototypes on one of my buildfarm >> animals, but the attempt failed because libreadline's headers are >> not clean. > It took me some time to reproduce the errors... > The rea

Re: Proposal: Support Logical replication of large objects

On Tue, Dec 2, 2025 at 6:41 PM Bernd Helmle wrote: > > Am Montag, dem 01.12.2025 um 09:27 +0530 schrieb Dilip Kumar: > > The decoder will then translate the standard single-row > > insert/update WAL records generated for the internal pg_largeobject > > table rows into logical operations formatted

Re: IPC/MultixactCreation on the Standby server

On 2025-Dec-04, Heikki Linnakangas wrote: > While working on the 64-bit multixid offsets patch, I noticed one more bug > with this. At offset wraparound, when we set the next multixid's offset in > RecordNewMultiXact, we incorrectly set it to 0 instead of 1. We're supposed > to skip over offset 1,

Re: Proposal: Conflict log history table for Logical Replication

On Wed, 3 Dec 2025 at 16:57, Dilip Kumar wrote: > > On Wed, Dec 3, 2025 at 9:49 AM shveta malik wrote: > > > > > > relid | 16391 > > > schemaname| public > > > relname | conf_tab > > > conflict_type | multiple_unique_conflicts > > > remote_xid| 761 > > >

Re: IPC/MultixactCreation on the Standby server

On 03/12/2025 19:19, Heikki Linnakangas wrote: On 03/12/2025 16:19, Dmitry Yurichev wrote: On 12/2/25 16:48, Heikki Linnakangas wrote: Thanks! Agreed, v14-16 were the same. v17 and v18 might be worth testing separately, to make sure I didn't e.g. screw up the locking differences. I tested on

Re: Remove unnecessary casts in printf format arguments

Hi, On Thu, Dec 04, 2025 at 01:19:07PM +0100, Peter Eisentraut wrote: > Attached are some patches to remove unnecessary casts in printf format > arguments. Many of these are apparently left over from before use of > %zu/%zd and PRIu64/PRId64 were possible. Additionally, there are a few > where t

Re: Adding REPACK [concurrently]

jian he wrote: > if (params.options & CLUOPT_ANALYZE) > ereport(ERROR, > errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > errmsg("cannot %s multiple tables", "REPACK (ANALYZE)")); > for this error case, adding a simple test case would be better? More options

Re: Cleanup shadows variable warnings, round 1

Hi, On Thu, 4 Dec 2025 at 14:21, Álvaro Herrera wrote: > > On 2025-Dec-04, Chao Li wrote: > > > The motivation is that CF’s CI currently fails on shadow-variable warnings. > > If you touch a file like a.c, and that file already has a legacy shadowing > > issue, CI will still fail your patch even

Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions

On Tue, Dec 2, 2025 at 1:23 PM jian he wrote: > > On Mon, Dec 1, 2025 at 8:09 PM Amul Sul wrote: > > > > Since you declared float8_div_safe() as static inline, I believe it > > wouldn't have any performance degradation since most compilers > > optimize it. Also, I suggest you pass the ErrorSafeCo

Re: Improve error reporting in 027_stream_regress test

Hi Michael, Brandon and Ben, Thank you for looking into this! On Thu, 4 Dec 2025 at 10:42, Michael Paquier wrote: > > On Wed, Dec 03, 2025 at 11:01:31PM -0800, Brandon Tat wrote: > > Regarding the function regression_log_helper(), this function reads > > all the lines in the logs at line 219 of

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

Hi, On Thu, Dec 04, 2025 at 12:06:44PM +0530, Shlok Kyal wrote: > On Thu, 4 Dec 2025 at 08:54, Dilip Kumar wrote: > > On Wed, Dec 3, 2025 at 10:59 AM Amit Kapila wrote: > > > On Fri, Nov 28, 2025 at 3:37 PM Michael Banck wrote: > > > > On Fri, Nov 28, 2025 at 03:30:48PM +0530, Amit Kapila wrote

Remove unnecessary casts in printf format arguments

Attached are some patches to remove unnecessary casts in printf format arguments. Many of these are apparently left over from before use of %zu/%zd and PRIu64/PRId64 were possible. Additionally, there are a few where the cast just cast to the type the input already had, or it just uselessly c

Re: Cleanup shadows variable warnings, round 1

On 2025-Dec-04, Chao Li wrote: > The motivation is that CF’s CI currently fails on shadow-variable warnings. > If you touch a file like a.c, and that file already has a legacy shadowing > issue, CI will still fail your patch even if your changes are correct. Then > you’re forced to fix unrelated s

Re: headerscheck ccache support

On 28.11.25 15:16, Álvaro Herrera wrote: On 2025-Nov-28, Peter Eisentraut wrote: But this doesn't seem to buy very much. The overhead of the shell script to write out the test files appears to become significant compared the the actual compile commands. If you wanted to save some shell execu

Re: headerscheck ccache support

On 28.11.25 14:29, Álvaro Herrera wrote: Another approach I had in mind for some time is to just write out a makefile with the test compile commands, and run that with make -j. Demo patch attached. (I'm not seriously proposing this. For one thing, we probably wouldn't want to introduce a depend

Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM

On Thu, 4 Dec 2025 at 14:17, Jelte Fennema-Nio wrote: > > On Thu, 4 Dec 2025 at 05:11, Kirill Reshke wrote: > > Hi! Superuser can change archive command to arbitrary bash, which is also > > useful for attacker. What should we do in this case? We definitely cannot > > restrict archive command ma

Re: headerscheck ccache support

On 28.11.25 14:10, Peter Eisentraut wrote: On 28.11.25 13:59, Álvaro Herrera wrote: On 2025-Nov-28, Nazir Bilal Yavuz wrote: I could not apply patches cleanly. Am I missing something? Yeah, I couldn't get `git am` or `git apply` to accept the patches either, not even with -3.  However, `patc

Re: Proposal: Conflict log history table for Logical Replication

On Thu, Dec 4, 2025 at 10:49 AM Dilip Kumar wrote: > > On Thu, Dec 4, 2025 at 7:31 AM Masahiko Sawada wrote: > > > > > The patch utilizes SPI for creating and dropping the conflict history > > table, but I'm really not sure if it's okay because it's actually > > affected by some GUC parameters su

Re: POC: make mxidoff 64 bits

On 26/11/2025 17:50, Heikki Linnakangas wrote: 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

Re: POC: make mxidoff 64 bits

On Wed, Dec 3, 2025 at 5:34 PM Heikki Linnakangas wrote: > > On 03/12/2025 11:54, Maxim Orlov wrote: > > The biggest problem with compression, in my opinion, is that losing > > even one byte causes the loss of the entire compressed block in the > > worst case scenario. After all, we still don't ha

Re: Remove unused function parameters, part 2: replication

Hi, On Thu, Dec 04, 2025 at 10:34:34AM +0100, Daniel Gustafsson wrote: > > On 2 Dec 2025, at 15:28, Bertrand Drouvot > > wrote: > > > That said I'm still skeptical that we need to provide a strong > > justification (as the one above) to remove an unused parameter. > > If it breaks an existing

Re: Use func(void) for functions with no parameters

Hi, On Wed, Dec 03, 2025 at 11:32:10PM -0500, Tom Lane wrote: > Bertrand Drouvot writes: > > The buildfarm animal remark makes me think to check with -Wstrict-prototypes > > and -Wold-style-definition. I just did that and found two more (added in v2 > > attached) that the coccinelle script missed

Re: POC: make mxidoff 64 bits

On Wed, 3 Dec 2025 at 15:04, Heikki Linnakangas wrote: > > There are plenty of such critical bytes in the system where a single bit > flip renders the whole block unreadable. Actually, if we had checksums > on SLRU pages, a single bit flip anywhere in the page would make the > checksum fail and r

Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION

On Wed, 3 Dec 2025 at 15:27, Hayato Kuroda (Fujitsu) < [email protected]> wrote: > Dear Maxim, > > I recalled my post [1]. The database id is helpful when we output lock > information by DescribeLockTag(). Since it would be called when the system > might > be under the deadlock, any locks

Re:Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication

On 28/11/2025 02:15, Fujii Masao wrote: > I've made a few minor adjustments to the test patch. > The updated version is attached. Hi, I was reading your code and had a question about the new code you added in the main() function of pg_recvlogical.c: if (outfd != -1 && strcmp(outfile, "-") !=

Re: Remove unused function parameters, part 2: replication

> On 2 Dec 2025, at 15:28, Bertrand Drouvot > wrote: > That said I'm still skeptical that we need to provide a strong > justification (as the one above) to remove an unused parameter. If it breaks an existing published API thus causing extensions to fail to compile then IMHO that's a pretty str

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

On Thu, Dec 4, 2025 at 1:54 PM Masahiko Sawada wrote: > > > I've attached the updated patch that incorporated the review comments > and is rebased to the current HEAD. > Thanks, a few things: 1) +The system automatically increases the +effective WAL level to logical when creatin

Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM

On Thu, 4 Dec 2025 at 05:11, Kirill Reshke wrote: > Hi! Superuser can change archive command to arbitrary bash, which is also > useful for attacker. What should we do in this case? We definitely cannot > restrict archive command management to localhost, are we? I'm curious why you think we cann

Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ...

Kindly review the attached patch , As i saw the proposed patch by Ian failed with CI https://commitfest.postgresql.org/patch/6244/ Guide me with the patch Regards, Vasuki M On Thu, Nov 27, 2025 at 2:50 PM VASUKI M wrote: > Hello all, > > Based on the discussion, I have updated the patch to hand

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

On Thu, Dec 4, 2025 at 5:04 PM shveta malik wrote: > > > I have just 2 trivial comments for v29-001: > > 1) > -   * receives a SIGINT from the startup process, or when there is an error. > +   * receives a SIGUSR1 from the startup process, or when there is an error. > > In above we should mention

Re: Fix crash during recovery when redo segment is missing

On Thu, Dec 04, 2025 at 12:00:23PM +0500, Kirill Reshke wrote: > Your tests are using a busy loop with usleep which nowadays is > considered as bad practice. There 3 of such places, and I think the > first two of them > can be replaced with injection point wait. (This fell off my radar, apologies

Re: tuple radix sort

> On Dec 4, 2025, at 13:30, John Naylor wrote: > > On Wed, Dec 3, 2025 at 3:22 PM Chao Li wrote: >> I played with this again today and found an optimization that seems to >> dramatically improve the performance: >> >> ``` >> +static void >> +radix_sort_tuple(SortTuple *begin, size_t n_elems

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Matthias van de Meent wrote: > On Mon, 1 Dec 2025 at 10:09, Antonin Houska wrote: > > > > Matthias van de Meent wrote: > > > > > I'm a bit worried, though, that LR may lose updates due to commit > > > order differences between WAL and PGPROC. I don't know how that's > > > handled in logical dec

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

On 03.12.2025 10:50, David Geier wrote: > On 19.11.2025 08:20, David Geier wrote: >> >> On 20.10.2025 21:59, Robert Haas wrote: >>> On Sun, Oct 19, 2025 at 2:16 PM Álvaro Herrera wrote: If I were a consultant trying to understand a customer's system, I would have to ask them to run