On Thu, Jun 19, 2025 at 5:11 AM Peter Eisentraut wrote:
> Here is a new patch.
>
> My previous patch was a bit too simple. I had thought that
> check_functions_in_node() does the node walking itself, but that was
> wrong, so the patch only worked at the top-level of the expression. So
> I had to
On Fri, Jun 20, 2025 at 11:09:01PM +0300, Nikita Malakhov wrote:
> I haven't found any comments on this and implemented
> a mechanism of setting custom reloptions for a relation
> created with Table AM, if needed. These options are stored
> in Relcache and are accessed through the rd_options field.
On Sat, Jun 21, 2025 at 1:39 AM Nikita Malakhov wrote:
> Hi hackers!
>
> While developing an alternative Table AM I've stumbled
> upon the impossibility to set custom reloptions to the table
> created by Table AM, like it could be done for Index AM.
>
> I haven't found any comments on this and im
Verified that the patch works w/ clang-19 -O0 and that avx-512 was selected
for
the CRC at runtime. Thanks for fixing this.
Regards,
Deep (VMware)
On Fri, Jun 20, 2025 at 04:53:52PM +0530, Rahila Syed wrote:
> Thank you for implementing these changes.
> The improvements look good and enhance the feature's utility. I have
> already started incorporating
> GetNamedDSA into my code to display memory context statistics.
Great! Thanks for the re
Hi hackers!
While developing an alternative Table AM I've stumbled
upon the impossibility to set custom reloptions to the table
created by Table AM, like it could be done for Index AM.
I haven't found any comments on this and implemented
a mechanism of setting custom reloptions for a relation
cre
Hello,
I'm writing in regards to a fix made in the last release of Postgresql
(specifically, I've looked at versions 15.13 and 16.9). The fix in question
is:
Fix data loss in logical replication
This is the change set:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9f21be08e
I d
On Fri, Jun 20, 2025 at 10:34:19AM +0900, Michael Paquier wrote:
> Hmm. I like the simplicity of option 2) for the purpose the back
> branches and the post-feature-freeze v18.
Yeah, let's do this for now.
> However, Option 1) would be my go-to option for HEAD (as of v19
> opening for business),
On Fri, Jun 20, 2025 at 11:05:37AM +0900, Michael Paquier wrote:
> On Thu, Jun 19, 2025 at 03:20:27PM -0500, Nathan Bossart wrote:
>> * vacuum_rel() does not look up the main relation's reloptions when
>> processing a TOAST table, which is a problem for manual VACUUMs. The
>> aforementioned bu
Re: Tom Lane
> Yeah, seems quite bogus. It's harmless though, so I don't
> see a need to back-patch, do you?
Other than it being confusing, it doesn't hurt.
Christoph
On Fri, Jun 20, 2025 at 10:15:47AM -0700, Jeff Davis wrote:
> On Fri, 2025-06-20 at 11:31 -0500, Nico Williams wrote:
> > In the slow path you only normalize the _current character_, so you
> > only need enough buffer space for that.
>
> That's a clear win for UTF8 data. Also, if there are no chan
pgxs.mk is cleaning up a file "regress.def" if PORTNAME=win, but the
only reference to that file I could find is in the original commit
from 1999 adding that "rm" rule (and several commits moving the rule
around later).
Given that the PORTNAME is wrong (should be win32), it's probably safe
to just
Hi!
I've noticed two bugs reported [0] and [1] which are both related to the
wraparound of mxid and
mxoff. Problems for mxid and mxoff are minor, as they require hitting the
exact overflow limit to
occur. But it's better to correct it.
I included a test to reproduce the problem (see 0001). It is
Hi,
On Thu, 19 Jun 2025 at 09:40, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Wed, 18 Jun 2025 at 11:58, Peter Eisentraut wrote:
> >
> > On 17.06.25 19:36, Peter Eisentraut wrote:
> > > meson.build currently says
> > >
> > > # We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
>
Christoph Berg writes:
> Re: Tom Lane
>> Yeah, seems quite bogus. It's harmless though, so I don't
>> see a need to back-patch, do you?
> Other than it being confusing, it doesn't hurt.
OK, applied to master only.
regards, tom lane
On Fri, 2025-06-20 at 17:51 +0300, Alexander Borisov wrote:
> I don't quite see how this compares to the implementation on Rust. In
> the link provided, they use perfect hash, which I get rid of and get
> a x2 boost.
> If you take ICU implementations in C++, I have always considered them
> slow, at
On Fri, 2025-06-20 at 11:31 -0500, Nico Williams wrote:
> In the slow path you only
> normalize the _current character_, so you only need enough buffer
> space
> for that.
That's a clear win for UTF8 data. Also, if there are no changes, then
you can just return the input buffer and not bother allo
On Thu, Jun 19, 2025 at 10:41:57AM -0700, Jeff Davis wrote:
> In addition to the lookups themselves, there are other opportunities
> for optimization as well, such as:
>
> * reducing the need for palloc and extra buffers, perhaps by using
> buffers on the stack for small strings
>
> * operate mor
On 20.06.25 15:29, Fabrice Chapuis wrote:
Regarding the changes made in version 15 for the traitment of the non-
numeric trailing characters, why does parsing continue to be permissive
with parentheses (no need to add a space)? Are we still in standard SQL?
Yes, a parenthesis is a "delimiter t
>> It's a bit odd that we have both `VacuumParams *params` and
>> `struct VacuumParams *params`.
Thanks for pointing that out, the attached new version fixed that.
>> I'd suggest just marking the VacuumParams *params with const...
I initially considered that approach. However, the current code p
19.06.2025 20:41, Jeff Davis wrote:
On Tue, 2025-06-03 at 00:51 +0300, Alexander Borisov wrote:
As promised, I continue to improve/speed up Unicode in Postgres.
Last time, we improved the lower(), upper(), and casefold()
functions. [1]
Now it's time for Unicode Normalization Forms, specifically
Christoph Berg writes:
> pgxs.mk is cleaning up a file "regress.def" if PORTNAME=win, but the
> only reference to that file I could find is in the original commit
> from 1999 adding that "rm" rule (and several commits moving the rule
> around later).
> Given that the PORTNAME is wrong (should be
Hi,
On 2025-06-20 09:46:06 +0800, James Pang wrote:
> same OS RHEL8, install pgv14.11 and pgv18.beta1_3, both installation by RPM
> from pgdg, and use similar postgresql.conf.
>
> 14.11
> Time: 55.082 ms
> postgres=# select * from tt where b ~~ 'a%';
> a | b
> ---+---
> (0 rows)
>
> Time: 54.
On Wed, Jun 18, 2025 at 12:33 AM John Naylor
wrote:
> Here's what numbers I'm looking at as well:
>
> *** normal
> meson options: -Dcassert=true -Ddebug=true -Dc_args='-Og'
> -Dc_args='-fno-omit-frame-pointer'
>
> $ meson test -q --print-errorlogs --suite setup && meson test -q
> --print-errorlog
On Fri, Jun 20, 2025 at 10:14 PM shihao zhong wrote:
>
> >> However, Option 1) would be my go-to option for HEAD ...
>
> Updated my patch to apply the same rules to all VacuumParams. Also I
> am seeing clusterParams as a pass reference, not sure if we should
> also change that to prevent future is
On Friday, June 20, 2025, Peter Eisentraut wrote:
> On 16.06.25 14:47, Jelte Fennema-Nio wrote:
>
>> # Draft CF
>>
>> There's now an additional Draft CF. People can move patches there as a
>> way of not forgetting about them. CFBot will rerun these patches less
>> frequently (exact behaviour TBD)
Fabrice Chapuis writes:
> Regarding the changes made in version 15 for the traitment of the non-numeric
> trailing characters, why does parsing continue to be permissive with
> parentheses (no need to add a space)?
A parenthesis cannot be part of a larger token, so I don't see
any ambiguity that
On Fri, Jun 20, 2025 at 9:34 AM Michael Paquier wrote:
>
> On Thu, Jun 19, 2025 at 03:30:26PM -0500, Nathan Bossart wrote:
> > After thinking about this some more, I'm wondering if it would be better to
> > pursue option (2) because it's a little less invasive (which is important
> > because this
On Thu, May 22, 2025 at 5:12 PM Amit Langote wrote:
> I have pushed out the revert now.
>
> Note that I’ve only reverted the changes related to deferring locks on
> prunable partitions. I’m planning to leave the preparatory commits
> leading up to that one in place unless anyone objects. For refer
Hi,
On 2025-05-24 09:09:36 +0900, Michael Paquier wrote:
> On Fri, May 23, 2025 at 11:56:59PM +0900, Fujii Masao wrote:
> > On 2025/05/22 8:58, Tom Lane wrote:
> >> Michael Paquier writes:
> >>> Another point perhaps worth considering after a second look: how about
> >>> pg_ci_base.conf? We have
On Fri, Jun 20, 2025 at 05:01:41PM +0300, Aleksander Alekseev wrote:
> Hi,
>
> > Given the quality of BSD indent code, I have _always_ found it easier to
> > modify pgindent. ;-
>
> :D Initially I thought that the problem was simple enough to solve it
> in C, but this turned out not to be true.
>> However, Option 1) would be my go-to option for HEAD ...
Updated my patch to apply the same rules to all VacuumParams. Also I
am seeing clusterParams as a pass reference, not sure if we should
also change that to prevent future issues. But that should be another
patch.
vacuum_tables_options_4
On Fri, Jun 20, 2025 at 04:44:08PM +0300, Aleksander Alekseev wrote:
> Hi Arseniy,
>
> > I tried it with the whole project and almost always it works great.
> > But I noticed two cases where it works probably not as expected:
> >
> > 1) comments which don't have a star on each line. For example:
>
Hi,
> Given the quality of BSD indent code, I have _always_ found it easier to
> modify pgindent. ;-
:D Initially I thought that the problem was simple enough to solve it
in C, but this turned out not to be true.
> It's going to be simpler to modify pgindent then. PFA the updated patch.
I noti
Hi Arseniy,
> I tried it with the whole project and almost always it works great.
> But I noticed two cases where it works probably not as expected:
>
> 1) comments which don't have a star on each line. For example:
> file 'cube.c'
>
> before:
> /* make up a metric in which one box will be 'lower'
Regarding the changes made in version 15 for the traitment of the non-numeric
trailing characters, why does parsing continue to be permissive with
parentheses (no need to add a space)? Are we still in standard SQL?
Regards
Fabrice
SELECT (123)order by 1;
+--+
| ?column? |
+--+
|
On 16.06.25 14:47, Jelte Fennema-Nio wrote:
# Draft CF
There's now an additional Draft CF. People can move patches there as a
way of not forgetting about them. CFBot will rerun these patches less
frequently (exact behaviour TBD). Draft CFs are never "In Progress"
and are open until the final CF
Hi Nathan,
>
> I like this idea, but I took it one step further in the attached patch and
> made the registry entry struct flexible enough to store any type of entry.
> Specifically, I've added a new "type" enum followed by a union of the
> different structs used to store the entry data. I was o
Hello!
This patch fixes CPPFLAGS, LDFLAGS, LIBS when checking AsyncDNS libcurl
support in configure
Custom parameters and paths to libcurl were mistakenly excluded from
CPPFLAGS, LDFLAGS, and LIBS, although AsyncDNS check was OK.
For example, the command `pkg-config --libs libcurl` gives
`
Hi David,
>Typically, in the regression tests we've used enable_sort to force a
>HashAgg. There are certainly times when that's not good enough and you
>might also need to disabe enable_indexscan too, so I understand the
desire to add this GUC.
Thank you for the explanation.
I wasn't aware that e
> On Fri, Jun 20, 2025 at 12:19:31PM +0200, Dmitry Dolgov wrote:
> Thanks! I've reworked the series to implement approach suggested by
> Thomas, and applied your patches to support buffers shrinking on top. I
> had to restructure the patch set, here is how it looks like right now:
The base-commit
On Sat, May 24, 2025 at 09:09:36AM +0900, Michael Paquier wrote:
> On Fri, May 23, 2025 at 11:56:59PM +0900, Fujii Masao wrote:
>> On 2025/05/22 8:58, Tom Lane wrote:
>>> I'd vote for standardizing on pg_regress.c's spelling, as that's got
>>> the most usage history behind it. I'm unexcited about
On Thu, Jun 19, 2025 at 4:34 PM shveta malik wrote:
>
> >
> > Here is the V38 patch set which includes the following changes:
> >
>
> Thank You for the patches. Few comments:
>
> 1)
> +
> +Note that commit timestamps and origin data retained by enabling the
> + linkend="sql-createsubscr
43 matches
Mail list logo
