Hi,
On Sat, 6 Dec 2025 at 04:40, Manni Wood wrote:
> Hello, all.
>
> Andrew, I tried your suggestion of just reading the first chunk of the copy
> file to determine if SIMD is worth using. Attached are v4 versions of the
> patches showing a first attempt at doing that.
Thank you for doing this
On 12/5/2025 3:24 PM, Bryan Green wrote:
> On 12/5/2025 2:48 PM, Robert Haas wrote:
>> On Fri, Dec 5, 2025 at 12:45 AM Bryan Green wrote:
>>> I tried implementing a PG_TRY/PG_CATCH approach and it doesn't work.
>>> The switch statement in set_config_with_handle() has multiple early
>>> returns (pa
Hello Álvaro and Mihail,
02.12.2025 15:07, Álvaro Herrera wrote:
Thanks, pushed this one after some more editorialization.
I've discovered that despite removing FIXME (in 90eae926a), the error
"invalid arbiter index list" can still be triggered with:
CREATE TABLE pt (a int PRIMARY KEY) PARTITI
On Fri, Dec 05, 2025 at 10:50:25AM +0300, Bilal Yavuz wrote:
> I liked your version more. My only complaint was removing the
> line_count argument but we can easily add it back when we need it.
Yes, I am not sure about that at this stage. It would be good to see
more use cases for this new API be
On Fri, Dec 5, 2025 at 3:25 PM Amit Kapila wrote:
>
> On Thu, Dec 4, 2025 at 4:20 PM Amit Kapila wrote:
> >
> > Also, shall we give the option to the user where she wants to see
> > conflict/resolution information? One idea to achieve the same is to
> > provide subscription options like (a) confl
On Wed, Nov 26, 2025 at 8:21 AM Manni Wood
wrote:
>
>
> 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
> On Dec 6, 2025, at 07:14, Tom Lane wrote:
>
> v5, rebased over a couple of recent patches. No substantive changes.
>
> I'd kind of like to get this pushed soon, because it keeps getting
> sideswiped ... does anyone have further comments?
Actually I traced v4 again this week. I tried to fi
> > However, as discussed off-list, I do think moving the custom kind tests from
> > injection points to the new test module is a prerequisite. I rather
> > not have us push a new test module that is doing duplicate work as the
> > injection
> > stats tests.
> > I worked on this refactoring today
On Sat, Dec 6, 2025 at 3:32 AM Jelte Fennema-Nio wrote:
> On Fri, 5 Dec 2025 at 02:30, Thomas Munro wrote:
> > How much of our header stuff is supposed to work from C++ too?
>
> I think it's nice if it works, but it doesn't seem the most important.
> Especially since C++ has its own hashmaps. And
On Thu, Dec 4, 2025 at 11:13 PM Masahiko Sawada wrote:
>
> On Thu, Dec 4, 2025 at 7:59 PM shveta malik wrote:
> >
> > On Fri, Dec 5, 2025 at 12:23 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Dec 4, 2025 at 1:30 AM shveta malik
> > > wrote:
> > > >
> > > > On Thu, Dec 4, 2025 at 1:54 PM
Hi Nathan,
I just reviewed v5, and overall looks very good patch quality. Just a few nit
comments on 0001 and 0003.
> On Dec 5, 2025, at 05:52, Nathan Bossart wrote:
>
>
> --
> nathan
>
1 - 0001
```
/* initialize options */
memset(&vacopts, 0, sizeof(vacopts));
vacopts.objfilter = 0;
v5, rebased over a couple of recent patches. No substantive changes.
I'd kind of like to get this pushed soon, because it keeps getting
sideswiped ... does anyone have further comments?
regards, tom lane
From c90691b8e5470583af72803f0dbfce90173d4ce6 Mon Sep 17 00:00:00 2
Hi Tom,
Thanks for the feedback.
If the syntax is like WHERE, there will be no way to do it without making
QUALIFY a fully-reserved word. That will inevitably break more than zero
applications.
You are right that QUALIFY functioning as a clause at the same level as WHERE /
HAVING creates gramm
On Fri, Dec 05, 2025 at 10:15:19AM -0600, Sami Imseih wrote:
> I am not sure how widely used this GUC is, but from the quick test that I
> did using pgench TPC-B workload with 50 clients, it seems useful
> since a DBA can set commit_delay too high and you will easily observe
> a single backend cons
On 05/12/2025 20:36, Andrey Borodin wrote:
On 5 Dec 2025, at 21:36, Maxim Orlov wrote:
It's good that the test was added. But it seems like it could be
improved a bit. The problem is, it only runs successfully with a
standard block size. Plus, the comment about the number of bytes was a
bit unc
On 12/5/2025 2:48 PM, Robert Haas wrote:
> On Fri, Dec 5, 2025 at 12:45 AM Bryan Green wrote:
>> I tried implementing a PG_TRY/PG_CATCH approach and it doesn't work.
>> The switch statement in set_config_with_handle() has multiple early
>> returns (parse failures, prohibitValueChange checks, etc.)
On Fri, Dec 5, 2025 at 5:40 PM Nathan Bossart
wrote:
> I don't think the proposed improvements are relevant for either of the
> machines you used for your benchmarks. For x86, we've optimized our
> popcount code to use SSE4.2 or AVX-512, and for AArch64, we've optimized
it
> to use Neon or SVE.
I wrote:
> Ah. Your script didn't notice the need for const'ification of
> additional variables in map_locale() :-(. I fixed that and
> pushed everything except the ecpg/preproc/variable.c changes,
> which I'm not too comfortable about yet. (The code coverage
> report shows that large chunks of
On Fri, Dec 5, 2025 at 12:45 AM Bryan Green wrote:
> I tried implementing a PG_TRY/PG_CATCH approach and it doesn't work.
> The switch statement in set_config_with_handle() has multiple early
> returns (parse failures, prohibitValueChange checks, etc.) that bypass
> both the success path and the P
On Fri, Dec 05, 2025 at 03:34:12PM -0500, Corey Huinker wrote:
>> I guess we could probably remove the top-level "Executing in dry-run mode"
>> message, provided we say the same thing in the per-database message.
>> However, the latter can be turned off with --quiet. Maybe we should
>> consider di
>
> I guess we could probably remove the top-level "Executing in dry-run mode"
> message, provided we say the same thing in the per-database message.
> However, the latter can be turned off with --quiet. Maybe we should
> consider disallowing --quiet and --dry-run.
>
--quiet does appear to be the
Hi David,
Thanks a lot for the detailed review, the fixes, and for pushing this
forward. I really appreciate the time you spent going through the
patch set
> 1. Moved block limiting logic for parallel scans into
> table_block_parallelscan_startblock_init(). There's currently a lock
> here to ensu
On Sat, 6 Dec 2025 at 01:08, Nathan Bossart wrote:
>
> Overall, I can't claim to have super principled arguments about where I've
> added these dry-run messages. I kind-of just sprinkled them around.
>
> --
Yep, sure, just polishing a patch. Let's remove the top-level message, indeed.
--
Be
On Sat, Dec 06, 2025 at 12:56:22AM +0500, Kirill Reshke wrote:
> Hi!
Thanks for reviewing.
>> +
>> + --dry-run
>> +
>> +
>> +Print, but do not execute, the vacuum and analyze commands that
>> would
>> +have been sent to the server (performs a dry run).
>> +
On Fri, 5 Dec 2025 at 02:52, Nathan Bossart wrote:
>
> On Thu, Nov 20, 2025 at 04:16:13PM -0600, Nathan Bossart wrote:
> > On Thu, Nov 20, 2025 at 05:09:54PM -0500, Corey Huinker wrote:
> >> I have no objections to, but I am curious about the factors that went into
> >> making dry_run an independe
> On 4 Dec 2025, at 19:17, Heikki Linnakangas wrote:
>
> I tried to modify the new wraparound TAP test to reproduce that, but it
> turned out to be difficult because you need to have multiple backends
> assigning multixids concurrently to hit that.
IIUC, new TAP test verifies multixact Id w
> >> 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 member to the proper array
> > size, and how can I zero-initialize the array with the correct le
> On 4 Dec 2025, at 00:07, Heikki Linnakangas wrote:
>
> I got a little annoyed by how lax pg_resetwal is about out-of-range values.
A little bit offtopic, but anyway.
It's kind of common practice for many tools.
We actually had a corruption after pg_upgrade inflicted by the bug in upgrade
> On 5 Dec 2025, at 21:36, Maxim Orlov wrote:
>
> It's good that the test was added. But it seems like it could be
> improved a bit. The problem is, it only runs successfully with a
> standard block size. Plus, the comment about the number of bytes was a
> bit unclear, for my taste. PFA patch,
On Wed, Dec 3, 2025 at 9:53 PM Richard Guo wrote:
> But I admit that I am unsure if this addresses
> any real problems, so the effort might not be justified. I agree that
> maybe we should just go ahead with your current patch and see what
> happens.
Thanks, I have committed that patch. So far t
On 04/12/2025 03:08, Chao Li wrote:
Hi Heikki,
This patch looks like a straightforward change, but I see a correctness issue
and a few small comments.
On Dec 4, 2025, at 03:07, Heikki Linnakangas wrote:
While working on the 64-bit multixid offsets patch and commit 94939c5f3a, I got
a littl
On Thu, Dec 04, 2025 at 05:40:21PM +, Zsolt Parragi wrote:
>> 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 member to the proper array
> size, and how
On 05/12/2025 17:33, Peter Eisentraut wrote:
There are many PG_GETARG_* calls, mostly around gin, gist, spgist code,
that are commented out, presumably to indicate that the argument is
unused and to indicate that it wasn't forgotten or miscounted. Example:
...
StrategyNumber strategy = (
On Fri, 28 Nov 2025 at 22:51, Heikki Linnakangas wrote:
>
> I moved the wraparound test to a separate test file and commit. More
> test coverage is good, but it's quite separate from the bugfix and the
> wraparound related test shares very little with the other test. The
> wraparound test needs a
Bertrand Drouvot writes:
> On Fri, Dec 05, 2025 at 09:47:56AM -0500, Tom Lane wrote:
>> Cool, how'd you find these?
> With the help of a coccinelle script. Will polish and share.
Ah. Your script didn't notice the need for const'ification of
additional variables in map_locale() :-(. I fixed tha
Hi,
> So, my colleague Ants Aasma found that a wait_event is missing for
> CommitDelay.
> This just looks like it was missed, please enlighten if it is left out
> intentionally.
I do not know if it was left out intentionally, there are no comments on that
matter.
I am not sure how widely used
Hi,
Can we support loser tree first and set the default value of enable_loser_tree
to off?
Anyway, I attach 2 patches. (pass check-world)
v2-0001: support tuplesort_heap_build() which can build a valid heap in O(n),
better
than currently O(n log n). This also make beginmerge() more clear and s
On Thu, Dec 04, 2025 at 06:40:42PM -0500, Corey Huinker wrote:
> Looking at them, I think they're all good. I think #3 is a must-have in all
> circumstances. I wouldn't be mad if we removed #1 or #2, but I see the
> value in each of them.
Alright. I think these are ready to go, but I'll wait for
On Fri, Dec 5, 2025 at 3:58 PM Euler Taveira wrote:
>
> On Thu, Dec 4, 2025, at 5:58 PM, Hannu Krosing wrote:
> > Please find attached a patch that makes tuple ids and info about
> > weather it was plain or HOT update available to logical decoding
> > callbacks.
> >
>
> My first impression was: wh
On Fri, Dec 05, 2025 at 03:07:07PM +0200, Andrew Pogrebnoi wrote:
> I want to propose an optimization for pg_popcount32_slow() and
> pg_popcount64_slow() where lookups into pg_number_of_ones[] are made
> branchless. It shows speedup around 58% for uint64 and 35% for uint32 words
> compared to the c
There are many PG_GETARG_* calls, mostly around gin, gist, spgist code,
that are commented out, presumably to indicate that the argument is
unused and to indicate that it wasn't forgotten or miscounted. Example:
...
StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);
/* Oi
On 2025-Dec-04, Mihail Nikalayeu wrote:
> Hello!
>
> Seems like it may be easily fixed (see attached patch).
Makes sense -- thanks, pushed.
> 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 c
On 29.11.25 21:50, Jeff Davis wrote:
All fixed, thank you! (I apologize for posting a patch in that state to
begin with...)
I also reorganized slightly to separate out the pg_iswcased() API into
its own patch, and moved the like_support.c changes from the ctype_is_c
patch (already committed: 147
Hi Postgres hackers,
This is my first patch to the project and I've been sitting on it for 6 months!
This patch was produced via:
git diff -p -U 4d936c3fff1ac8dead2cc240ba3da2ed6337257c
The branch point was 4d936c3fff1ac8dead2cc240ba3da2ed6337257c (master
as of 05/12/2025 1445 GMT)
The patch,
On Thu, Dec 4, 2025, at 5:58 PM, Hannu Krosing wrote:
> Please find attached a patch that makes tuple ids and info about
> weather it was plain or HOT update available to logical decoding
> callbacks.
>
My first impression was: why do you want to expose an internal information that
is mostly usele
Hi David,
Thanks for looking at it!
> I would like to test if I can reproduce your results. Could you share
> your test program?
Here you go:
https://gist.github.com/dAdAbird/1480ff15764f5a6301174806d8512a3a
> You also don't specify an optimization level. That means the default
> level -O0 is u
Hi,
On Fri, Dec 05, 2025 at 09:47:56AM -0500, Tom Lane wrote:
> Bertrand Drouvot writes:
> > What about adding the 4 in the attached?
>
> Cool, how'd you find these?
With the help of a coccinelle script. Will polish and share.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Ope
Bertrand Drouvot writes:
> What about adding the 4 in the attached?
Cool, how'd you find these?
regards, tom lane
David Geier writes:
> My bad. I hadn't realized that - obviously - not necessarily all code is
> actually compiled by default.
> Will the build system enable any target for which all dependencies (e.g.
> libraries) are met, or are there targets that need to be enabled
> explicitly? Is there a way
Calling copyObject fails in C++ with an error like in most setups:
error: use of undeclared identifier 'typeof'; did you mean 'typeid'
This is due to the C compiler supporting used to compile postgres
supporting typeof, but that function actually not being present in the
C++ compiler. This fixes
On Fri, 5 Dec 2025 at 02:30, Thomas Munro wrote:
> How much of our header stuff is supposed to work from C++ too?
I think it's nice if it works, but it doesn't seem the most important.
Especially since C++ has its own hashmaps. And if it really needs to
create a hashmap it's still possible to cal
Jelte Fennema-Nio writes:
> On Thu, 4 Dec 2025 at 19:49, Kirill Reshke wrote:
>> Again, if we are using GUC to tell somebody something about security,
>> this doesn't work. Superuser can easily redefine any GUC.
> If you mark this GUC as PGC_BACKEND it cannot be changed with SET
> commands, not
Hi,
On Thu, Dec 04, 2025 at 05:09:30PM -0500, Tom Lane wrote:
> Attached is a patch that cleans up all the cases I saw on a local
> rawhide installation.
What about adding the 4 in the attached?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Ser
On Fri, Nov 28, 2025 at 6:35 PM Ashutosh Bapat
wrote:
>
>
> I will continue reviewing it further.
>
There is duplication of code/functionality between server and
pg_upgrade. With it we carry all the risks that come with
code/functionality duplication like the copies going out of sync.
There may b
On 01/08/2025 00:48, Jacob Champion wrote:
On Fri, Jul 18, 2025 at 11:11 AM Jacob Champion
wrote:
The attached still needs some documentation work
v2 does a bunch of commit message work, but I imagine it needs a good
bit of copy-editing for clarity.
I'm not in any hurry to smash this in. I t
Hi Andy!
On 05.12.2025 14:07, Andrew Pogrebnoi wrote:
> Hello hackers,
>
> I want to propose an optimization for pg_popcount32_slow() and
> pg_popcount64_slow() where lookups into pg_number_of_ones[] are made
> branchless. It shows speedup around 58% for uint64 and 35% for uint32 words
> compared
Hello hackers,
I want to propose an optimization for pg_popcount32_slow() and
pg_popcount64_slow() where lookups into pg_number_of_ones[] are made
branchless. It shows speedup around 58% for uint64 and 35% for uint32 words
compared to the current, looped version. This is on x86. It is much more
si
On 05.12.2025 08:41, Michael Paquier wrote:
> On Thu, Dec 04, 2025 at 10:31:41AM +0100, David Geier wrote:
>> Attached are the two patches, rebased on latest master.
>>
>> The first one contains all changes that either result in no changes to
>> the disassembly, or only in changes due to the line c
On Thu, Dec 4, 2025 at 12:12 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, December 4, 2025 1:58 PM Amit Kapila
> wrote:
> >
> > On Thu, Dec 4, 2025 at 2:04 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Dec 2, 2025 at 10:15 PM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > I think the
On 01/08/2025 00:48, Jacob Champion wrote:
On Fri, Jul 18, 2025 at 11:11 AM Jacob Champion
wrote:
The attached still needs some documentation work
v2 does a bunch of commit message work, but I imagine it needs a good
bit of copy-editing for clarity.
I'm not in any hurry to smash this in. I t
Hello,
On 2025-Dec-04, Donghang Lin wrote:
> Hi Álvaro,
>
> Thanks for looking at it. The test in the commit still fails back to 14.
> I think it should be backported to 14 and up.
You're correct that the bug is older. I'm not sure about backporting
the fix to 16 and earlier though, because it
On Thu, 4 Dec 2025 at 19:49, Kirill Reshke wrote:
> > Good question. I think the easiest would be to always disallow FROM
> > PROGRAM (by default) instead of only when connecting over the network.
>
> How? with GUC?
I meant, sidestep this problem completely by not doing my idea of
still allowing
On Thu, Dec 4, 2025 at 11:35 PM Mihail Nikalayeu
wrote:
>
> Hello!
>
> Thanks for the patch.
Thanks for reviewing :)
> Few comments:
>
> 1) tests are failing, expected output files need to be updated
Yes, I didn't want to start changing tests before other parts stabilized a bit.
> 2)
> > * Tre
On Fri, Dec 5, 2025 at 3:25 PM Amit Kapila wrote:
>
> On Thu, Dec 4, 2025 at 4:20 PM Amit Kapila wrote:
> >
> > Also, shall we give the option to the user where she wants to see
> > conflict/resolution information? One idea to achieve the same is to
> > provide subscription options like (a) confl
Hello there,
So, my colleague Ants Aasma found that a wait_event is missing for
CommitDelay. This just looks like it was missed, please enlighten if it is
left out intentionally.
For now, I worked on this patch to add it.
--
Regards,
Rafia Sabih
CYBERTEC PostgreSQL International GmbH
0001-Add-
On Thu, Dec 4, 2025 at 4:20 PM Amit Kapila wrote:
>
> Also, shall we give the option to the user where she wants to see
> conflict/resolution information? One idea to achieve the same is to
> provide subscription options like (a) conflict_resolution_format, the
> values could be log and table for
On 04/12/2025 16:36, Álvaro Herrera wrote:
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.
Hi,
On Fri, Dec 05, 2025 at 12:38:16PM +0500, Kirill Reshke wrote:
> On Fri, 5 Dec 2025, 12:32 Michael Banck, wrote:
> The idea here is that you get OOM which will lead to restart.
Right, but you only get OOM if you have memory overcommit enabled (or
are running Postgres in a cgroupv2 container)
On Fri, Dec 5, 2025 at 10:47 AM Dilip Kumar wrote:
>
> On Fri, Dec 5, 2025 at 9:24 AM vignesh C wrote:
> >
>
> > 2) Is there a way to unset the conflict log table after we create the
> > subscription with conflict_log_table option
>
> IMHO we can use ALTER SUBSCRIPTION...WITH(conflict_log_table='
On Fri, Nov 28, 2025 at 2:59 PM Michael Banck wrote:
>
> On Thu, Nov 27, 2025 at 11:08:00AM +0530, Shlok Kyal wrote:
> > I have addressed the comments and attached the updated patch.
>
> Maybe it would be better to break out the slotsync parts of
> pg_replication_slots into a new view?
>
We have
On Thu, Dec 4, 2025 at 5:59 PM Michael Banck wrote:
>
> 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:
>
Hello, hackers!
A few days ago Karina Litskevich noticed that strict function with
variadic argument containing a few values, only one of which was NULL,
returned NULL without evaluating the function itself. It didn't match
with documented behaviour:
"If a function is declared STRICT with a
> On 4 Dec 2025, at 19:01, Tom Lane wrote:
> On the other hand, aligning the C++ compiler with the C compiler
> is likely to avoid other problems, so maybe it's better to focus
> on making that happen. I'm not sure how we'd do that automatically
> though.
It sounds pretty complicated to, with c
73 matches
Mail list logo
