On Fri, Nov 21, 2025, 17:25 Jacob Champion
wrote:
> On Fri, Nov 21, 2025 at 2:01 PM
>
> Actually, maybe brevity is best, as in v2?
>
Looks fine to me
>
> On Nov 22, 2025, at 00:14, Fujii Masao wrote:
>
> On Fri, Nov 21, 2025 at 6:24 PM Chao Li wrote:
>> No, what I was thinking is that, we could combine the three set statement
>> into one, like:
>>
>> ```
>> Set a = 1; set b = 2; set c = 3;
>> ```
>> So that sends a single statement to publ
Hi hi
Many tools that implement wait event analysis, when visualizing samples
with "wait_event is null" use green color and "CPU" (perhaps, it started
with RDS Performance Insights and PASH Viewer and, I suppose, originally
came from the Oracle world, and now I see it in many more places).
I don'
On Fri, Nov 21, 2025 at 2:01 PM Jacob Champion
wrote:
> Good point. I think "actual protocol version" might get a little
> confusing for a casual reader if/when your _GREASE macro arrives,
> though. I'll do some wordsmithing.
Actually, maybe brevity is best, as in v2? They're reserved, they're
sp
I wrote:
> Although I've left the patch throwing an error (with new wording)
> for now, I wonder if it'd be better to reduce the error to a NOTICE,
> perhaps worded like "function f will be effectively temporary due to
> its dependence on ".
This is, of course, pretty much what you suggested origi
(shamelessly splitting this into its own thread, but also to avoid
further derailment of Neustradamus' tls-exporter conversation)
On Fri, Nov 21, 2025 at 3:15 PM Nico Williams wrote:
> For apps like PG I'm much more interested in real OAuth support. But
> that's because I use PG in a corporate e
Jim Jones writes:
> PFA v6 with these changes.
I went through this and made one big change and some cosmetic ones.
The big change is that it makes zero sense to me to apply this
restriction only to new-style SQL functions. If it's bad for an
allegedly non-temporary function to disappear at sess
Hi,
On 2025-11-21 18:14:56 -0500, Peter Geoghegan wrote:
> On Fri, Nov 21, 2025 at 5:38 PM Andres Freund wrote:
> > Another benfit is that it helps even more when there multiple queries
> > running
> > concurrently - the high rate of lock/unlock on the buffer rather badly hurts
> > scalability.
On Fri, Nov 21, 2025 at 02:57:26PM -0800, Jacob Champion wrote:
> On Fri, Nov 21, 2025 at 11:57 AM Nico Williams wrote:
> > (I'm very down on SCRAM. I'd much rather have an asymmetric zero-
> > knowledge PAKE.)
>
> Hey, get an OPAQUE-PLUS over the line and I bet someone here will take
> interest
On Fri, Nov 21, 2025 at 5:38 PM Andres Freund wrote:
> Another benfit is that it helps even more when there multiple queries running
> concurrently - the high rate of lock/unlock on the buffer rather badly hurts
> scalability.
I haven't noticed that effect myself. In fact, it seemed to be the
oth
On Fri, Nov 21, 2025 at 11:57 AM Nico Williams wrote:
> (I'm very down on SCRAM. I'd much rather have an asymmetric zero-
> knowledge PAKE.)
Hey, get an OPAQUE-PLUS over the line and I bet someone here will take
interest :D
(It's hard for me to be more down on SCRAM than I am on plaintext
LDAP,
>
>
> A few small comments.
>
> 1. Minor typo fixes:
>
+1 Thanks.
> 2.Code maintainability suggestion:
> I noticed the string "malformed pg_dependencies: "%s"" is used repeatedly
> throughout the code. Would you consider defining this as a macro? This
> could reduce duplication and make future u
Hi,
On 2025-11-10 18:59:07 -0500, Peter Geoghegan wrote:
> Tomas and I had a meeting on Friday to discuss a way forward with this
> project. Progress has stalled, and we feel that now is a good time to
> pivot by refactoring the patch into smaller, independently
> useful/committable pieces.
Makes
> On 13 Nov 2025, at 00:12, Daniel Gustafsson wrote:
>
>> On 12 Nov 2025, at 18:47, Álvaro Herrera wrote:
>>
>> On 2025-Nov-12, Daniel Gustafsson wrote:
>>
>>> As far as I know the only way to programmatically learn that from the Perl
>>> testcode would be to check for the presence of the CONF
On 2025-11-18 Tu 2:56 PM, Robert Haas wrote:
In general, I don't think that whether or not a GUC's parsed value can
be serialized easily into a single palloc'd chunk is a good measure of
whether it's too complicated.
+1
I agree, of course, that we shouldn't
randomly sandwhich a bunch of
>
> > The same logic applies to RangeVarGetRelidExtendedSafe() and
> > makeRangeVarFromNameListSafe. These can be called from
> > RangeVarGetRelidExtended() and makeRangeVarFromNameList(),
> > respectively.
> > --
> >
>
> I don’t see any way to pass the escontext (ErrorSaveContext) without
> changi
On 2025-07-18 Fr 3:19 AM, Ashutosh Bapat wrote:
Hi All,
On Mon, Jan 27, 2025 at 11:22 AM Ashutosh Bapat
wrote:
On Mon, Nov 25, 2024 at 7:06 PM Nazir Bilal Yavuz wrote:
It is added and marked as ready for the committer [1]. There are
multiple 'Jian He' users in the commitfest app, so I coul
On Fri, Oct 31, 2025 at 2:40 PM Robert Haas wrote:
> Thoughts?
I guess not.
I spent a bunch more time investigating what was going on with the one
problematic test case that I mentioned in my previous email. I
discovered that my prior analysis missed a key point about this test
case, which is th
On Fri, Nov 21, 2025 at 1:39 PM Jelte Fennema-Nio wrote:
> Overall seems like reasonable restructuring. I think this note feels out of
> place now though:
>
> * The cancel request code must not match any protocol version number
> * we're ever likely to use. This random choice should do.
>
> I thi
On Fri, Nov 21, 2025, 12:10 Jacob Champion
wrote:
>
> WDYT?
>
Overall seems like reasonable restructuring. I think this note feels out of
place now though:
* The cancel request code must not match any protocol version number
* we're ever likely to use. This random choice should do.
I think it'
>
> Other initial comments:
>
> The commit message says:
>
> This is managed via two new options, fetch_stats and remote_analyze,
> both are available at the server level and table level. If fetch_stats
> is true, then the ANALYZE command will first attempt to fetch
> statistics
> f
On Fri, Nov 21, 2025 at 03:14:15PM -0500, Tom Lane wrote:
> I spent a little time staring at the v5 patches. Obviously there
> are a bunch of minor details to be verified, which you've carefully
> provided XXX comments about, and I didn't really go through those
> yet. There are two big-picture q
Hi,
On 2025-11-21 01:44:31 +0100, Andreas Karlsson wrote:
> On 11/20/25 11:34 AM, Tomas Vondra wrote:
> > On 11/19/25 22:03, Andreas Karlsson wrote:
> > > I have been following these discussions but not read the patch in detail.
> > >
> > > This patch makes me worried especially with the new issu
I spent a little time staring at the v5 patches. Obviously there
are a bunch of minor details to be verified, which you've carefully
provided XXX comments about, and I didn't really go through those
yet. There are two big-picture questions that are bothering me:
1. I do not think I believe the p
On Fri, Nov 21, 2025 at 11:42:41AM -0800, Jacob Champion wrote:
> On Fri, Nov 21, 2025 at 11:17 AM Nico Williams wrote:
> > Well, you're right that if we're talking about a Heartbleed type leak
> > then what I said does not follow. However loss of the TLS server
> > credential's private keys is s
On Fri, Nov 21, 2025 at 01:17:09PM +0100, Tomas Vondra wrote:
> True. Hence the stress testing I've been doing - and indeed, that made
> us discover the various issues reported in this thread.
>
> Still, isn't that similar to error paths in various other patches? Those
> also tend to be rarely exe
On Nov 20 2025, at 7:08 pm, Thomas Munro wrote:
> On Fri, Nov 21, 2025 at 9:45 AM Greg Burd wrote:
>> Dave and I have been working together to get ARM64 with MSVC functional.
>> The attached patches accomplish that. Dave is the author of the first
>> which addresses some build issues and fixe
On Fri, Nov 21, 2025 at 01:52:07PM -0500, Tom Lane wrote:
> But the conclusion that "where t1.a = t2.a and t1.b = 0" means that
> t1's rowcount is 1 only applies if the join is implemented as an inner
> indexscan. If we choose some other method, say a hash join based on
> a seqscan of t1, having f
On Fri, Nov 21, 2025 at 11:17 AM Nico Williams wrote:
> Well, you're right that if we're talking about a Heartbleed type leak
> then what I said does not follow. However loss of the TLS server
> credential's private keys is still close enough to catastrophic.
Sure, but it's nice that SCRAM (the
On Nov 20 2025, at 5:36 pm, Nathan Bossart wrote:
> I took a quick look at 0001.
Thanks for taking a second to review!
> +#ifdef _MSC_VER
> +#include
> +#else
> #include
> unsigned int crc;
>
> I think you can remove this since we unconditionally do the runtime check
> for MSVC. In any ca
On Nov 20 2025, at 7:07 pm, Andres Freund wrote:
> Hi,
>
> On 2025-11-20 19:03:47 -0500, Andres Freund wrote:
>> > MSVC's _InterlockedCompareExchange() intrinsic on ARM64 performs the
>> > atomic operation but does NOT emit the necessary Data Memory Barrier
>> > (DMB) instructions [4][5].
>>
On Nov 20 2025, at 7:03 pm, Andres Freund wrote:
> Hi,
>
> On 2025-11-20 15:45:22 -0500, Greg Burd wrote:
>> Dave and I have been working together to get ARM64 with MSVC functional.
>> The attached patches accomplish that. Dave is the author of the first
>> which addresses some build issues a
On Fri, Nov 21, 2025 at 10:21:41AM -0800, Jacob Champion wrote:
> On Fri, Nov 21, 2025 at 9:38 AM Nico Williams wrote:
> > If the attacker has the server's private keys then presumably also have
> > the credentials needed to also terminate the SASL/GSS-API mechanism's
> > server/acceptor side, so
Hi,
I was reviewing a patchset by Jelte [1] and decided that pqcomm.h has
gotten hard to read/organize.
Attached is a patch that groups the magic PG_PROTOCOL() codes, adds a
comment to a typedef that was orphaned when protocol.h arrived, and
tweaks some whitespace to make the "paragraphs" easier
"=?utf-8?B?ZmVpY2hhbmdob25n?=" writes:
> We may consider checking in cardinality estimation whether the restrictlist
> fully covers a unique index. If so, we can directly set the estimated rows
> to 1. The attached patch provides a very early demo of this approach.
I think this is far harder than
Hi Corey,
This is an important feature. Thanks for working on it.
On Mon, Nov 3, 2025 at 2:26 PM Corey Huinker wrote:
>> My point is: rather than trying to implement a second solution with a
>> new callback, shouldn't we try to rework the existing callback so as
>> it would fit better with wha
On Fri, Nov 21, 2025 at 9:28 AM Nico Williams wrote:
> The main benefit of "end-point"-style CB data is that it's easier to
> deal with server-side ("reverse") proxies. That's primarily a benefit
> for HTTP applications, and almost certainly not relevant to PG (unless
> there _are_ reverse proxie
This email is just a review for some (specified below) of the patches 0001-0007
On Wed, Nov 19, 2025 at 9:47 PM Andres Freund wrote:
>
> 0002: Not really required, but seems like an improvement to me
The commit message says the point is to get compiler warnings for
switch cases that should be ex
On Fri, Nov 21, 2025 at 06:24:07PM +0100, Daniel Gustafsson wrote:
> > On 21 Nov 2025, at 17:38, Jacob Champion
> > wrote:
>
> > In the past, we've said that we're going to wait for published RFCs,
> > and I think that's served us well.
>
> I am a strong supporter of this strategy.
+1
On Thu, Nov 20, 2025 at 01:59:22PM -0800, Jacob Champion wrote:
> On Thu, Nov 20, 2025 at 1:52 PM Heikki Linnakangas wrote:
> > PostgreSQL does support channel binding, with tls-server-end-point. I
> > believe that sufficient to prevent an attack like that.
>
> No, IIRC unique bindings (-unique a
On Thu, Nov 20, 2025 at 08:58:54PM +, * Neustradamus * wrote:
> - XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
> - XEP-0440: SASL Channel-Binding Type Capability:
> https://xmpp.org/extensions/xep-0440.html
> - XEP-0474: SASL SCRAM Downgrade Protection:
> https
On Fri, Nov 21, 2025 at 08:30:42AM +, * Neustradamus * wrote:
> Dear Heikki,
>
> Thanks for your answer.
>
> Several people would like to deprecate "tls-server-end-point" (RFC 5929) like
> Simon Josefsson (author of several RFCs) because RFC 9266 exists since July
> 2022:
We must either fi
On Thu, Nov 20, 2025 at 11:52:07PM +0200, Heikki Linnakangas wrote:
> > After the jabber.ru MITM, it is time to add it:
>
> PostgreSQL does support channel binding, with tls-server-end-point. I
> believe that sufficient to prevent an attack like that. (Assuming that it's
> configured correctly, bu
> On 21 Nov 2025, at 17:38, Jacob Champion
> wrote:
> In the past, we've said that we're going to wait for published RFCs,
> and I think that's served us well.
I am a strong supporter of this strategy.
--
Daniel Gustafsson
On Fri, 2025-11-21 at 15:21 +0100, Dmitry Dolgov wrote:
> > > + ctl.hcxt = CurrentMemoryContext;
> >
> > That hashtable should stick around for the entire life time of the backend.
> > Wouldn't it be better to explicitly name the correct memory context, rather
> > that to rely on being calle
> On Nov 22, 2025, at 00:54, feichanghong wrote:
>
> Hi,
>
> Recently, I ran into a cardinality estimation problem where the query
> predicates fully cover a primary key or unique index. The issue can be
> reproduced with the following case:
>
> ```sql
> create table t1(a int, b int, primary
Hi,
Recently, I ran into a cardinality estimation problem where the query
predicates fully cover a primary key or unique index. The issue can be
reproduced with the following case:
```sql
create table t1(a int, b int, primary key(a, b));
DO $$
DECLARE
i integer;
BEGIN
FOR i IN 1..1000
On Fri, Nov 21, 2025 at 12:49 AM * Neustradamus *
wrote:
> At the same time, about these XEPs, it is the base of the
> "draft-melnikov-sasl2" done by Alexey Melnikov (author of several RFCs):
> - https://datatracker.ietf.org/doc/html/draft-melnikov-sasl2
Right, but even that draft says
All
Hi Sawada-san,
Thank you for your additional feedback on v4!
>We can initialize dead_items_max_bytes when declared.
Thank you. I fixed it as you mentioned.
>Does it need to check if vacrel->dead_items is non-NULL?
Thank you. I fixed it as you mentioned.
>I think we should not use "index scans"
On Fri, Nov 21, 2025 at 12:46 AM Heikki Linnakangas wrote:
> If I understood the incident correctly, the attacker managed to somehow
> obtain a valid TLS certificate for the victim domain. They used that to
> perform a MITM attack. They did not have the server's private key. (Or
> if they did, the
Andres Freund writes:
> On 2025-11-21 12:11:38 +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, otherwise pglz. This would be similar to other
On Fri, Nov 21, 2025 at 6:24 PM Chao Li wrote:
> No, what I was thinking is that, we could combine the three set statement
> into one, like:
>
> ```
> Set a = 1; set b = 2; set c = 3;
> ```
> So that sends a single statement to publisher server, that reduces round-trip
> from 3 times to one time
I wrote:
> I have a distinct recollection that this comment exists because we
> found that some platforms had a hypot() that got that edge case wrong.
> I don't object to proceeding on the assumption that they all conform
> to spec by now, but please make sure there's at least one regression
> test
Hi,
On 2025-11-21 12:11:38 +0100, Peter Eisentraut wrote:
> How about changing the default of default_toast_compression to lz4?
>
> I have seen cases where servers had performance problems and were CPU-bound
> because of pglz TOAST compression, and changing it to lz4 relieved it
> significantly.
On 20.11.25 14:33, Bertrand Drouvot wrote:
I was working on something similar to [1] (which led to 7f798aca1d5) and I think
that 7f798aca1d5 missed removing some useless casts to (void *).
committed, thanks
Hi,
On 2025-11-21 13:14:18 +0100, Álvaro Herrera wrote:
> On 2025-Nov-21, Peter Eisentraut wrote:
> ># Verify headerscheck / cpluspluscheck succeed
> >#
> > - # - Don't use ccache, the files are uncacheable, polluting ccache's
> > - # cache
>
> So how bad is the effect of the cache po
Hi,
On 2025-11-21 11:48:10 +0100, Peter Eisentraut wrote:
> Currently, headerscheck and cpluspluscheck are very slow, and they defeat
> use of ccache. I have fixed that, and now they are much faster. :-)
>
> The problem was (I think) that the test files are created in a
> randomly-named director
Peter Eisentraut writes:
> I have been hunting down the last few pieces of code that made some
> obsolete claims about not being able to use C99 yet or needing to be
> compatible with pre-C99 or something like that. I found two obsolete
> comments and two places where we could now actually use
On Wed, 19 Nov 2025 at 19:00, Greg Burd wrote:
>
> Attached are rebased (d5b4f3a6d4e) patches with the only changes
> happening in the last patch in the series.
Here's a high-level review of the patchset, extending on what I shared
offline. I haven't looked too closely at the code changes.
Re: P
On 2025-11-20 Th 7:55 AM, Nazir Bilal Yavuz wrote:
Hi,
Thank you for looking into this!
On Thu, 20 Nov 2025 at 00:01, Nathan Bossart wrote:
IMHO we should be looking for ways to simplify this should-we-use-SIMD
code. For example, perhaps we could just disable the SIMD path for 10K or
100K
Thanks for the detailed review! I generally agree with most of the
points and will try to incorporate them into the next version. Below are
few commentaries / questions for the rest.
> On Wed, Nov 19, 2025 at 09:57:12PM +0100, Laurenz Albe wrote:
> On Sun, 2025-11-16 at 17:45 +0100, Dmitry Dolgov
On Wed, Nov 19, 2025, at 7:44 AM, Alvaro Herrera wrote:
> On 2025-Nov-18, Euler Taveira wrote:
>> The "backend type" terminology is exposed.
>
> Something appearing in the source code does not equate it being exposed
> to end users. Things are exposed when they are in the documentation, or
> when
On Sat, Nov 22, 2025 at 2:50 AM Peter Eisentraut wrote:
+ * %z doesn't actually act differently from %Z on Windows.
Probably obsolete too, at least according to:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?view=msvc-170
On 21/11/2025 14:15, Ashutosh Bapat wrote:
On Mon, Nov 17, 2025 at 10:05 PM Heikki Linnakangas wrote:
Ashutosh, you were interested in reviewing this earlier. Would you have
a chance to review this now, before I commit it?
0002 seems to be fine. It's just moving code from one file to another
I have been hunting down the last few pieces of code that made some
obsolete claims about not being able to use C99 yet or needing to be
compatible with pre-C99 or something like that. I found two obsolete
comments and two places where we could now actually use the C99
functionality that the c
Hi Ashutosh,
Just wanted to let you know that I've submitted this patch
to CommitFest (see https://commitfest.postgresql.org/patch/6245/)
Interestingly enough there is one more patch from Mircea Cadariu in the same
CommitFest about pgbench (https://commitfest.postgresql.org/patch/6242/)
That patc
On 2025-Nov-21, Heikki Linnakangas wrote:
> I don't feel the urge to refactor this myself right now, but we probably
> could simplify this further. For example, I wonder if we should remove
> is_an_int() altogether and rely on strtoi64() to return failure if the input
> does't look like a integer.
On 19.11.25 16:48, Tom Lane wrote:
No further comments.
This has been committed.
FWIW, I don't have any plans currently to work on upgrading the code to
newer upstream versions.
On 20/11/2025 05:36, Chao Li wrote:
I have no concern if we decide to no longer support tailing spaces, while I
still got a couple of small comments:
1
```
-/* return whether str matches "^\s*[-+]?[0-9]+$" */
+/*
+ * Return whether str matches "^\s*[-+]?[0-9]+$"
+ *
+ * This should agree with s
Ian Lawrence Barwick writes:
> Hi
>
> I found myself needing to work with ALTER ROLE ... IN DATABASE ... recently
> and was annoyed by the lack of tab completion for this, so patch attached.
A noble goal, but unfortunately th RESET form can't work properly due to
limitations of the tab completio
On Fri, 21 Nov 2025 at 15:41, Shlok Kyal wrote:
>
> On Fri, 21 Nov 2025 at 11:00, shveta malik wrote:
> >
> > On Fri, Nov 21, 2025 at 9:58 AM Amit Kapila wrote:
> > >
> > > On Fri, Nov 21, 2025 at 8:52 AM shveta malik
> > > wrote:
> > > >
> > > > On Tue, Nov 18, 2025 at 4:07 PM Shlok Kyal
>
> On 21 Nov 2025, at 12:33, Aleksander Alekseev
> wrote:
>> The default could be lz4 if
>> lz4 support is built, otherwise pglz. This would be similar to other
>> parameters where the default is the best one depending on the build
>> configuration.
+1
> Are there good reasons why we can't sim
On 11/21/25 01:44, Andreas Karlsson wrote:
> On 11/20/25 11:34 AM, Tomas Vondra wrote:
>> On 11/19/25 22:03, Andreas Karlsson wrote:
>>> Hi,
>>>
>>> I have been following these discussions but not read the patch in
>>> detail.
>>>
>>> This patch makes me worried especially with the new issues re
On Mon, Nov 17, 2025 at 10:20 AM Amul Sul wrote:
>
> On Thu, Nov 6, 2025 at 2:33 PM Amul Sul wrote:
> >
> > On Mon, Oct 20, 2025 at 8:05 PM Robert Haas wrote:
> > >
> > > On Thu, Oct 16, 2025 at 7:49 AM Amul Sul wrote:
> > > []
> > Kindly have a look at the attached version. Thank you !
> >
On Mon, Nov 17, 2025 at 10:05 PM Heikki Linnakangas wrote:
>
> Ashutosh, you were interested in reviewing this earlier. Would you have
> a chance to review this now, before I commit it?
0002 seems to be fine. It's just moving code from one file to another.
However, the name multixact_internals.h
On 2025-Nov-21, Peter Eisentraut wrote:
> Currently, headerscheck and cpluspluscheck are very slow, and they defeat
> use of ccache. I have fixed that, and now they are much faster. :-)
Yeah, I had noticed this too. Thanks for fixing it.
> My solution is to create the test files in the build d
On 21.11.25 01:49, Bruce Momjian wrote:
Actually, another discussion would be why we have src/tools/codelines in
the git tree at all. I added it in 2005 to use in counting code lines,
and I thought we could consider it our standard method, but I am not
sure anyone aside from me even uses it, and
Hi,
On Thu, Nov 20, 2025 at 04:59:07PM +, Bertrand Drouvot wrote:
> On Wed, Nov 19, 2025 at 10:49:49PM +0900, Michael Paquier wrote:
> >
> > Hmm. I can think about an option 3 here: pg_buffercache outlines the
> > view pg_buffercache_numa as the primary choice over
> > pg_buffercache_numa_pa
Hi,
If a process encounters a FATAL error after acquiring a dshash lock but
before releasing it,
and it is not within a transaction, it can lead to a segmentation fault.
The FATAL error causes the backend to exit, triggering proc_exit() and
similar functions.
In the absence of a transaction, LWLo
On Wed, Nov 19, 2025 at 1:50 PM Jakub Wartak
wrote:
>
> On Mon, Nov 17, 2025 at 5:51 AM Amul Sul wrote:
> >
> > On Thu, Nov 6, 2025 at 2:33 PM Amul Sul wrote:
> > >
> > > On Mon, Oct 20, 2025 at 8:05 PM Robert Haas wrote:
> > > >
> > > > On Thu, Oct 16, 2025 at 7:49 AM Amul Sul wrote:
> > > >
Hi Bruce,
> Actually, another discussion would be why we have src/tools/codelines in
> the git tree at all. I added it in 2005 to use in counting code lines,
> and I thought we could consider it our standard method, but I am not
> sure anyone aside from me even uses it, and it is clear there are
Hi hackers,
While working on [1], I noticed that there are unused fields in
BufferCacheNumaRec
since ba2a3c2302f.
Also, I noticed that a comment was not at the correct location in
pg_buffercache_numa_pages().
The attached takes care of both.
[1]:
https://www.postgresql.org/message-id/aR9I29Q
Hi Peter,
> How about changing the default of default_toast_compression to lz4?
To me it sounds like a great idea.
> I have seen cases where servers had performance problems and were
> CPU-bound because of pglz TOAST compression, and changing it to lz4
> relieved it significantly. I suspect man
How about changing the default of default_toast_compression to lz4?
I have seen cases where servers had performance problems and were
CPU-bound because of pglz TOAST compression, and changing it to lz4
relieved it significantly. I suspect many users are leaving easy
performance improvements o
Currently, headerscheck and cpluspluscheck are very slow, and they
defeat use of ccache. I have fixed that, and now they are much faster. :-)
The problem was (I think) that the test files are created in a
randomly-named directory (`mktemp -d /tmp/$me.XX`), and this
directory is named on t
On Fri, 21 Nov 2025 at 11:30, Amit Kapila wrote:
>
> On Fri, Nov 21, 2025 at 11:00 AM shveta malik wrote:
> >
> > A few comments on 001:
> >
> > 1)
> > +slots, but may (if leftover from a promotedstandby) contain a
> > timestamp.
> > promotedstandby --> promoted standby
> >
> > 2)
> > +
On Fri, 21 Nov 2025 at 09:58, Amit Kapila wrote:
>
> On Fri, Nov 21, 2025 at 8:52 AM shveta malik wrote:
> >
> > On Tue, Nov 18, 2025 at 4:07 PM Shlok Kyal wrote:
> > >
> > > On Fri, 14 Nov 2025 at 14:13, Hayato Kuroda (Fujitsu)
> > > wrote:
> > > >
> > > > Dear Shlok,
> > > >
> > > > Thanks fo
On Fri, 21 Nov 2025 at 11:00, shveta malik wrote:
>
> On Fri, Nov 21, 2025 at 9:58 AM Amit Kapila wrote:
> >
> > On Fri, Nov 21, 2025 at 8:52 AM shveta malik wrote:
> > >
> > > On Tue, Nov 18, 2025 at 4:07 PM Shlok Kyal
> > > wrote:
> > > >
> > > > On Fri, 14 Nov 2025 at 14:13, Hayato Kuroda (
Fixed a compile warning in v4.
Best regards,
Chao Li (Evan)
-
HighGo Software Co., Ltd.
https://www.highgo.com/
On Fri, Nov 21, 2025 at 1:52 PM Chao Li wrote:
>
> On Thu, Nov 20, 2025 at 8:28 PM Álvaro Herrera
> wrote:
>
>> Hi,
>>
>> > -appendStringInfo(&bu
On Thu, 20 Nov 2025 at 17:36, Nathan Bossart
wrote:
> I took a quick look at 0001.
>
> +#ifdef _MSC_VER
> +#include
> +#else
> #include
> unsigned int crc;
>
> I think you can remove this since we unconditionally do the runtime check
> for MSVC. In any case, the missing #endif seems likely t
> On Nov 21, 2025, at 15:47, Fujii Masao wrote:
>
>>
>> 4. The commit message:
>> ```
>> This commit removes the restriction by changing how logical replication
>> connections are established so that GUC settings in the CONNECTION string
>> are properly passed through to and uesd by the walse
On Fri, Nov 21, 2025 at 9:14 AM Ajin Cherian wrote:
>
>
> Attaching patch v24, addressing the above comments.
>
Thanks for the patch. Please find a few comments:
1)
Instead of passing an argument to slotsync_reread_config and
ProcessSlotSyncInterrupts, we can use 'AmLogicalSlotSyncWorkerProcess
Dear Jacob Champion,
Thanks for your answer.
Links of XEPs are here to confirm that "tls-exporter" is needed and already
used.
XEPs are already supported by a lot of projects/softwares/companies in
production, for example on GitHub, we can see:
-
https://github.com/search?q=XEP-0480+-repo%3Ax
On 20/11/2025 23:59, Jacob Champion wrote:
On Thu, Nov 20, 2025 at 1:52 PM Heikki Linnakangas wrote:
PostgreSQL does support channel binding, with tls-server-end-point. I
believe that sufficient to prevent an attack like that.
No, IIRC unique bindings (-unique and -exporter) prevent MITM even
On Mon, Nov 17, 2025 at 9:43 PM Amul Sul wrote:
>
> 10-0004:
>
> +/* error safe version of textToQualifiedNameList */
> +List *
> +textToQualifiedNameListSafe(text *textval, Node *escontext)
>
> If I am not mistaken, it looks like an exact copy of
> textToQualifiedNameList(). I think you can simpl
Dear Heikki,
Thanks for your answer.
Several people would like to deprecate "tls-server-end-point" (RFC 5929) like
Simon Josefsson (author of several RFCs) because RFC 9266 exists since July
2022:
- https://mailarchive.ietf.org/arch/msg/kitten/zpesKSHsiuy1RvhPlbSUGajLbKQ/
- https://datatracker.
Hi all,
Attach the rebased patches.
Some useful link:
Discussion:
https://www.postgresql.org/message-id/flat/[email protected]
https://www.postgresql.org/message-id/flat/[email protected]
https://www.postgresql.org/message-id
97 matches
Mail list logo
