On Wed, Dec 3, 2025 at 8:56 AM shveta malik wrote:
>
> On Wed, Nov 19, 2025 at 3:34 PM Shlok Kyal wrote:
> >
> >
> > I have also addressed the comments in [1], [2].
> >
> > [1]:
> > https://www.postgresql.org/message-id/CAHut%2BPtRzCD4-0894cutkU_h8cPNtosN0_oSHn2iAKEfg2ENOQ%40mail.gmail.com
> > [
Bertrand Drouvot writes:
> On Wed, Dec 03, 2025 at 10:15:41AM -0500, Tom Lane wrote:
>> Some years ago we had a buildfarm animal that would complain about
>> this construct, so the tree used to be clean. Probably it's just
>> chance that these have only snuck into local functions.
> The buildfar
On Thu, Dec 4, 2025 at 11:56 AM jian he wrote:
>
> On Mon, Dec 1, 2025 at 5:16 AM David E. Wheeler wrote:
> >
> > Well-spotted, thank you! Fixed in v15, attached.
> >
>
> seems no deparse regress tests, like:
> create view vj as select jsonb_path_query('" hello "', '$.ltrim(" ")') as
> a;
>
On Thu, 4 Dec 2025, 07:24 Jelte Fennema-Nio, wrote:
>
>
> On Wed, Dec 3, 2025, 22:01 Tom Lane wrote:
>
>> I think the idea of putting training wheels on superuser is pretty
>> hopeless; there's too many ways in which that allows escape to the OS,
>> and even if we could close them all, the resul
On Mon, Dec 1, 2025 at 5:16 AM David E. Wheeler wrote:
>
> On Nov 28, 2025, at 05:29, jian he wrote:
>
> > some "switch" in the attached patch does not preserve the JsonPathItemType
> > order
> > consistency, like executeItemOptUnwrapTarget.
>
> Well-spotted, thank you! Fixed in v15, attached.
>
Hi,
Thank you for your reply.
> Can we drive the decision for what to do based on optimizer
> stats, i.e. n_distinct and row counts? Not sure what the calculation would
> be specifically, but something else to consider.
>
> We can still provide the GUC to override the optimizer decisions,
> but
On Thu, Dec 4, 2025 at 8:03 AM Masahiko Sawada wrote:
>
> On Mon, Dec 1, 2025 at 12:54 AM shveta malik wrote:
> >
> > On Mon, Dec 1, 2025 at 11:40 AM Masahiko Sawada
> > wrote:
> > >
> > >
> > > > 11)
> > > > my ($result, $stdout, $stderr) = $standby4->psql('postgres',
> > > > qq[select pg_logi
> On Dec 4, 2025, at 01:31, Peter Geoghegan wrote:
>
>
> Note also that we'll use much less memory for killedItems by
> representing it as a Bitmapset. We'll use at most one bit per
> so->currPos.items[] item, whereas before we used 4 bytes per item.
>
That’s true, BitmapSet saves 7/8 of me
On Wed, Dec 3, 2025 at 10:59 AM Amit Kapila wrote:
>
> On Fri, Nov 28, 2025 at 3:37 PM Michael Banck wrote:
> >
> > Hi,
> >
> > On Fri, Nov 28, 2025 at 03:30:48PM +0530, Amit Kapila wrote:
> > > I suggested the current one because having the last was making the
> > > column name bit longer, and a
On Thu, 4 Dec 2025 at 07:47, Peter Smith wrote:
>
> On Wed, Dec 3, 2025 at 4:47 PM tianbing wrote:
> >
> > Hi， Peter，
> > I have reviewed the v21 patch and noticed that there seems to be a memory
> > leak.
> >
> > +static bool
> > +check_publication_exists(PGconn *conn, const char *pubname, cons
On Wed, Dec 3, 2025 at 11:03 PM Robert Haas wrote:
> It's a reasonable concern, but I think we should go ahead with the
> patch anyway and see what happens. I believe that comment emerged from
> some problems with buildfarm instability around the time that code was
> committed -- I want to say tha
On Mon, Dec 1, 2025 at 12:54 AM shveta malik wrote:
>
> On Mon, Dec 1, 2025 at 11:40 AM Masahiko Sawada wrote:
> >
> >
> > > 11)
> > > my ($result, $stdout, $stderr) = $standby4->psql('postgres',
> > > qq[select pg_logical_slot_get_changes('standby4_slot', null, null)]);
> > > like(
> > > $stderr
On Wed, Dec 3, 2025, 22:01 Tom Lane wrote:
> I think the idea of putting training wheels on superuser is pretty
> hopeless; there's too many ways in which that allows escape to the OS,
> and even if we could close them all, the resulting system would be
> very much less useful than today.
>
I de
On Wed, Dec 3, 2025 at 4:47 PM tianbing wrote:
>
> Hi， Peter，
> I have reviewed the v21 patch and noticed that there seems to be a memory
> leak.
>
> +static bool
> +check_publication_exists(PGconn *conn, const char *pubname, const char
> *dbname)
> +{
> + PGresult *res;
> + bool exists;
> + cha
On Thu, Dec 4, 2025 at 12:33 AM Andres Freund wrote:
> On 2025-12-02 13:10:29 +0900, Amit Langote wrote:
> > On Fri, Nov 21, 2025 at 8:45 PM Rahila Syed wrote:
> > > If a process encounters a FATAL error after acquiring a dshash lock but
> > > before releasing it,
> > > and it is not within a tr
Hi
> As a software developer, I definitely want to > implement compression and
> save a few gigabytes. However, given my previous experience using
> Postgres in real-world applications, reliability at the cost of several
> gigabytes would not have caused me any trouble. Just saying.
Agree +1, If t
On Wed, Dec 3, 2025 at 3:27 AM 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
> >
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 little annoyed by how lax pg_resetwa
FWIW... A few more review comments for v3.
//
Patch v3-0001.
//
==
src/backend/access/gist/gistbuild.c
2.1.
OK, but should you take it 1 step further?
BEFORE
foreach(lc, splitinfo)
{
GISTPageSplitInfo *si = lfirst(lc);
AFTER
foreach_ptr(GISTPageSplitInfo, si, splitinfo)
{
On Fri, Nov 28, 2025 at 11:11:04AM +0200, Heikki Linnakangas wrote:
> I don't know if we've agreed on a goal of getting rid of all shadowing, it's
> a lot of code churn. I agree shadowing is often confusing and error-prone,
> so maybe it's worth it.
(Providing my own context with more information
Hi Corey
I was reviewing the recent patch
v19-0003-Include-Extended-Statistics-in-pg_dump.patch and noticed a couple of
small typo issues in the explanatory comments — nothing that affects the
functionality.
Here are the two minor fixes I’d suggest:
1. “ndistintinct” should be “ndistinct”.
2.
On Tue, Dec 02, 2025 at 11:36:39AM +0100, David Bidoc wrote:
> I attached the rebased patch.
> Any feedback would be appreciated.
Your patch still fails to apply on HEAD for all the changes of
contrib/oid2name/oid2name.c. Please see the following:
https://commitfest.postgresql.org/patch/6111/
It
I forgot to mention this point earlier.
I noticed GENERIC_PLAN is hard-coded to 1 (true).
Is that an oversight, or is it required?
```
+ GENERIC_PLAN 1, \
```
--
Sami Imseih
Amazon Web Services (AWS)
On Mon, Nov 24, 2025 at 6:06 PM Shinya Kato wrote:
>
> On Tue, Nov 25, 2025 at 8:13 AM Masahiko Sawada wrote:
> > > What about “started_by” ? it’s unambiguous and consistent with other
> > > columns
> > > like “query_start” in pg_stat_activity.
> >
> > "started_by" sounds reasonable to me.
>
> T
> I ran into this when I was
> working on GetNamedDSA() and GetNamedDSHash()
Thanks for mentioning these, I didn't notice them when I rebased on
the master branch. One of my use cases was this, I implemented
something similar to GetNamedDSHash - it's a generic wrapper for
dshash in C++, and I ran
> On 3 Dec 2025, at 22:27, Jelte Fennema-Nio wrote:
>
> On Wed, 3 Dec 2025 at 17:57, Heikki Linnakangas wrote:
>>> I really want to make it possible for anyone who don't want SNI to keep
>>> using
>>> postgresql.conf and get the exact behavior they've always had. Do you agree
>>> with that des
On Mon, Nov 24, 2025 at 3:08 AM Chao Li wrote:
>
> > On Nov 21, 2025, at 09:09, Chao Li wrote:
> >
> > I’d stop here today, and continue reviewing rest commits in next week.
>
> I continue reviewing today.
I incorporated all your feedback in my recently posted v23. Thanks for
the review!
- Mela
> On Dec 4, 2025, at 05:00, Peter Smith wrote:
>
> On Thu, Dec 4, 2025 at 1:36 AM Álvaro Herrera wrote:
>>
>> On 2025-Dec-03, Chao Li wrote:
>>
>>> Unfortunately that doesn’t work for my compiler (clang on MacOS),
>>> that’s why I renamed “I" to “u”.
>>
>> I think you're missing his point.
On Tue, Dec 2, 2025 at 3:42 AM Sugamoto Shinya wrote:
>
>
>
> On Sat, Nov 29, 2025 at 9:36 PM Sugamoto Shinya wrote:
>>
>>
>>
>> On Fri, Nov 28, 2025 at 2:59 AM Kirill Reshke wrote:
>>>
>>> On Wed, 26 Nov 2025 at 11:55, Sugamoto Shinya wrote:
>>> >
>>> >
>>> >
>>> > 2025年11月25日(火) 6:50 Nathan B
> I have refactored the commit on the latest version of PG and added a few more
> tests.
Thanks for the update!
> To simplify the roll out of this feature, I decided to work on analyze=false
> use case first.
I did not go through the entire patch yet, but a few things stood out
from my first p
On Wed, 3 Dec 2025 at 17:57, Heikki Linnakangas wrote:
> > I really want to make it possible for anyone who don't want SNI to keep
> > using
> > postgresql.conf and get the exact behavior they've always had. Do you agree
> > with that design goal?
>
> Yeah, that's fair.
What if we make it so th
On Wed, Jun 11, 2025 at 1:29 PM Peter Geoghegan wrote:
> Removing BTScanPosUnpinIfPinned allows me to significantly simplify
> the management of buffer pins with mark/restore. The patch also gets
> rid of all of the calls to IncrBufferRefCount made from
> nbtree, since it's no longer necessary to
On Tue, Dec 2, 2025 at 2:39 PM Peter Smith wrote:
>
> On Mon, Dec 1, 2025 at 4:50 PM Masahiko Sawada wrote:
> >
> > On Thu, Nov 27, 2025 at 12:33 AM Peter Smith wrote:
> > >
> > > Hi Sawada-San.
> > >
> > > Some review comments for v30-0001.
> >
> > Thank you for the comments!
> >
> > > ==
>
On Wed, Dec 03, 2025 at 02:59:16PM -0600, Sami Imseih wrote:
> Yes, that's true. It will be hard to find other good use-cases that
> can't be solved with a global variable, but we can also say this is
> a low-cost change, so why not just do it.
Well, for one, it requires all existing extensions th
Nathan Bossart writes:
> On Wed, Dec 03, 2025 at 11:35:07AM -0800, Jacob Champion wrote:
>> Could initdb be made to instead give you a user with the power to
>> manage almost all of the database (i.e. pg_maintain/pg_monitor), but
>> without the power to touch anything outside it or execute arbitra
On Thu, Dec 4, 2025 at 1:36 AM Álvaro Herrera wrote:
>
> On 2025-Dec-03, Chao Li wrote:
>
> > Unfortunately that doesn’t work for my compiler (clang on MacOS),
> > that’s why I renamed “I" to “u”.
>
> I think you're missing his point. He's suggesting to change not only
> this variable, but also t
> On Wed, Dec 03, 2025 at 02:27:29PM -0600, Sami Imseih wrote:
> > There are probably other good reasons to allow a generic argument
> > to the init callback. Besides the lwlock name, I can see someone
> > wanting to pass some other initialization info that may vary
> > depending on extension GUCs,
Surya Poondla (cc'd) and I took another look at this as part of the
November Patch Review Workshop.
We think it looks good. But I couldn't get the latest patch to apply
on top of REL_17_STABLE until I did this:
```
git am inplace160-inval-durability-inplace-v7.patch_v17
git revert bc6bad8857 # re
On Wed, Dec 03, 2025 at 02:27:29PM -0600, Sami Imseih wrote:
> There are probably other good reasons to allow a generic argument
> to the init callback. Besides the lwlock name, I can see someone
> wanting to pass some other initialization info that may vary
> depending on extension GUCs, etc.
The
On Wed, Dec 03, 2025 at 11:35:07AM -0800, Jacob Champion wrote:
> Yeah, these conversations tend to get stuck right at this point.
> Restricting superuser so that it's somehow not superuser is a huge
> (intractable?) undertaking. Doing it a piece at a time doesn't make a
> lot of sense if we're not
On Tue, Dec 2, 2025 at 10:15 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, December 3, 2025 12:26 AM Masahiko Sawada
> wrote:
> >
> > On Mon, Dec 1, 2025 at 10:19 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Tuesday, December 2, 2025 1:03 AM Masahiko Sawada
> > wrote:
> > > >
> > > > O
> My gut feeling is that this is an obscure enough use-case that this
> workaround is probably sufficient, but I am interested to hear more...
There are probably other good reasons to allow a generic argument
to the init callback. Besides the lwlock name, I can see someone
wanting to pass some oth
Building only a subset of libraries / binaries would be sufficient for our
use case (and even only building a subset of the tree would get us most of
the way there).
A configure-time switch to only build client binaries would be ideal but
perhaps that could be a long term goal.
In our fork we tri
On Wed, Dec 03, 2025 at 12:47:46PM -0600, Sami Imseih wrote:
> Can you provide more details on the use-case?
I think the main use-case is creating multiple DSM segments in the registry
that use the same initialization callback. I ran into this when I was
working on GetNamedDSA() and GetNamedDSHas
Hi Kirill,
These are great examples, thanks. I wasn't aware it was that easy to chain
config overwrite and crash/restart from plain SQL.
Taken together, that makes it clear this GUC buys less than I'd hoped, and
is probably not worth the extra complexity on its own.
Please consider this patch wi
On Wed, Dec 3, 2025 at 9:03 AM Nathan Bossart wrote:
> See also this recent discussion about a --with-copy-program compile flag:
>
>
> https://postgr.es/m/flat/CAGRrpza_WUY_jaN4P-xkN%3DTdqfxH%2BeJJazZAo5gg%3DkQoEaQnVw%40mail.gmail.com
Yeah, these conversations tend to get stuck right at
On 12/3/25 19:33, Tom Lane wrote:
> I wrote:
>> Yeah, I can imagine that constantly flushing the cached plan for
>> that plpgsql function would be bad. Let me see if I can reformulate
>> that test without using a plpgsql function --- right offhand, it's
>> not obvious why a built-in function wo
On 01/12/2025 14:35, Ashutosh Bapat wrote:
On Mon, Dec 1, 2025 at 2:23 PM Maxim Orlov wrote:
On Fri, 28 Nov 2025 at 16:17, Ashutosh Bapat
wrote:
An UPDATE waits for FOR SHARE query to finish, and vice versa. In my
experiments I didn't see an UPDATE creating a multi-xact. Why do we
have UPDAT
On 27.11.25 03:53, Thomas Munro wrote:
I wondered about this in the context of special alignment
requirements[1]. palloc() aligns to MAXALIGN, which we artificially
constrain for various reasons that we can't easily change (at least
not without splitting on-disk MAXALIGN from allocation MAXALIGN
While working on the 64-bit multixid offsets patch and commit
94939c5f3a, I got a little annoyed by how lax pg_resetwal is about
out-of-range values. These are currently accepted, for example:
# Negative XID
pg_resetwal -D data -x -1000
# XID larger than 2^32 (on some platforms)
pg_resetwal
Hi there,
Thanks for raising this topic! I am currently working on a POC patch that
adds extended statistics for joins. I am polishing the patch now and will
post it soon with performance numbers, since there are interests!
On Mon, Dec 1, 2025 at 7:16 PM Corey Huinker
wrote:
> On Mon, Dec 1, 20
Hi Hackers,
While reviewing
https://www.postgresql.org/message-id/CACJufxGoAmN_0iJ%3DhjTG0vGpOSOyy-vYyfE%2B-q0AWxrq2_p5XQ%40mail.gmail.com,
I noticed that when you create a domain on a rangetype, you don't get
a corresponding multirange. For instance:
```
[v19devel:5432][481380] mr=# create domai
Hi,
Can you provide more details on the use-case?
> For example, the documentation for creating LWLocks after startup [1]
> suggests creating locks in this callback. That works fine as long as
> the callback only needs to create a hardcoded lock.
The callback is called on the first invocation of
Hi Hackers,
While reviewing
https://www.postgresql.org/message-id/CACJufxGoAmN_0iJ%3DhjTG0vGpOSOyy-vYyfE%2B-q0AWxrq2_p5XQ%40mail.gmail.com,
I noticed this inconsistency in how ranges enforce domains over their
subtypes:
```
[v19devel:5432][426675] postgres=# create type int4_d_range;
CREATE TYPE
On Tue, Dec 2, 2025 at 11:39 PM jian he wrote:
>
> While working on domain IS JSON, I found out that
> WITHOUT OVERLAPS does not support for domain too.
> but it does support user-defined range types (via CREATE TYPE).
>
> after looking around:
> check_exclusion_or_unique_constraint->ExecWithoutOv
I wrote:
> Yeah, I can imagine that constantly flushing the cached plan for
> that plpgsql function would be bad. Let me see if I can reformulate
> that test without using a plpgsql function --- right offhand, it's
> not obvious why a built-in function wouldn't serve the purpose
> just as well.
I
On Wed, 3 Dec 2025 at 23:17, I wrote:
> (I did derive the exact example
> when postgresql immediately restarts after some SQL but im 100% there
> is such thing )
Shame on me
select repeat('a',1024*1024*1023) from generate_series(1, 100);
--
Best regards,
Kirill Reshke
On Wed, 3 Dec 2025 at 23:02, Ignat Remizov wrote:
>
> On Wed, Dec 3, 2025 at 7:23 PM Kirill Reshke wrote:
> > HI! As mentioned here and in nearby threads there is no security
> > boundary there between pg superuser and os.
> >
> > Particularly, PGC_POSTMASTER restricts nothing, and
> > GUC_DISALL
Hi,
Thanks for raising this.
> Now we use 'heap' during the k-way merge, it's O(n log k). The 'loser tree'
> is also O(n log k), but
> it's usually has fewer comparisons than the 'heap'. When the tuple comparator
> is complex, the
> 'loser tree' can significantly speed up the k-way merge.
I wa
Hello hackers,
While developing an extension and trying to write some generic code
around DSM areas, I noticed a limitation: although GetNamedDSMSegment
accepts a callback function, there is no way to pass additional
arguments to that callback.
For example, the documentation for creating LWLocks
Hello, everyone!
On Wed, Dec 3, 2025 at 3:41 PM Álvaro Herrera wrote:
> I think it's odd that conflict resolution depends on log entries. I
> think it would be much more valuable if conflict reporting would save
> the details of the conflict to some kind of conflict logging table.
> How exactly
On Wed, Dec 3, 2025 at 7:23 PM Kirill Reshke wrote:
> HI! As mentioned here and in nearby threads there is no security
> boundary there between pg superuser and os.
>
> Particularly, PGC_POSTMASTER restricts nothing, and
> GUC_DISALLOW_IN_AUTO_FILE does not prevent superuser access to
> postgresql
On 01/12/2025 14:40, Heikki Linnakangas wrote:
On 30/11/2025 14:15, Andrey Borodin wrote:
On 29 Nov 2025, at 00: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 r
On Wed, Dec 3, 2025 at 7:32 AM Chao Li wrote:
> The old code only sets so->numKilled to 0 and reuse memory of
> so->killedItems[], now the new code always bms_free(so->killedItems) and
> re-alloc memory when next time adding a member to bms.
>
> I am think that, if there were bms_clear(), then w
On 2025-Dec-03, Andrew Dunstan wrote:
> +1. One of the things I find particularly un-aesthetic is having some
> branches of an if statement with braces and some without. We have lots of
> cases of that, but I try to avoid it.
I actually prefer that style: when there are only two branches, and the
On Wed, 3 Dec 2025 at 21:45, Ignat Remizov wrote:
>
> Thanks for the feedback Euler.
>
> On Wed, Dec 3, 2025 at 5:59 PM Euler Taveira wrote:
> > You are blocking one of the various ways to run malicious code using the
> > postgres user. If it doesn't work the attacker will try another method. If
On Tue, Dec 2, 2025 at 3:30 PM Ashutosh Bapat
wrote:
>
> On Tue, Nov 25, 2025 at 7:22 PM Peter Eisentraut wrote:
>
> >
> > - I'm not so sure about the semantics chosen in the patch "Access
> > permissions on property graph". I think according to the SQL standard,
> > once you have access to the
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 the REL_18_1 tag (with applying v15-pg18-0001-S
On Wed, Dec 03, 2025 at 10:02:44AM -0500, Tom Lane wrote:
> This argument is nonsense, because if you've got superuser you can
> just change the GUC's setting again. Not to mention all the *other*
> ways that a superuser can break out to the OS level. I don't think
> this proposal adds anything e
On 03/12/2025 18:52, Daniel Gustafsson wrote:
On 3 Dec 2025, at 10:57, Heikki Linnakangas wrote:
Do we need the GUC? It feels a little confusing that a GUC affects how the
settings in the pg_hosts.conf are interepreted. It'd be nice if you could open
pg_hosts.conf in an editor, and see at one
Committed.
--
nathan
> On 3 Dec 2025, at 10:57, Heikki Linnakangas wrote:
>
> Sorry for jumping in so late.
Not at all, thanks for looking!
> Do we need the GUC? It feels a little confusing that a GUC affects how the
> settings in the pg_hosts.conf are interepreted. It'd be nice if you could
> open pg_hosts.conf
Thanks for the feedback Euler.
On Wed, Dec 3, 2025 at 5:59 PM Euler Taveira wrote:
> You are blocking one of the various ways to run malicious code using the
> postgres user. If it doesn't work the attacker will try another method.
If you
> want to prevent the majority of attacks, you need to for
On Wed, Dec 03, 2025 at 03:53:37PM +, Bertrand Drouvot wrote:
> 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...
>
> Those new two (run_app
Hi,
On 2025-12-02 19:47:35 -0500, Andres Freund wrote:
> On 2025-11-25 11:54:00 -0500, Andres Freund wrote:
> > Thanks a lot for that detailed review! A few questions and comments,
> > before I
> > try to address the comments in the next version.
>
> Here's that new new version, with the follow
On Wed, Dec 3, 2025, at 7:37 AM, Ignat Remizov wrote:
> In practice, COPY ... PROGRAM is a common code execution vector in
> PostgreSQL-based attacks. It is:
>
> - Simple to use (single SQL statement)
> - Requires no additional extensions or setup
> - Frequently targeted by automated botnets
On 2025-Dec-03, Mihail Nikalayeu wrote:
> Oh, my bad, sorry.
> Attached patch with output variant for
> RELCACHE_FORCE_RELEASE\CATCACHE_FORCE_RELEASE case.
I have pushed this, thanks.
> But for CLOBBER_CACHE_ALWAYS - it is just a mess, too many different
> kinds of wakeup loops need to be done.
Hi,
On Wed, Dec 03, 2025 at 10:13:55AM -0500, Andres Freund wrote:
> On 2025-12-03 08:14:41 +, Bertrand Drouvot wrote:
> > So, what about documenting them all?
>
> I'm -0.1 on that. I think it's just as likely that those code comments will
> not be moved when another chunk of memory is needed
Hi,
On Wed, Dec 03, 2025 at 10:15:41AM -0500, Tom Lane wrote:
> Matthias van de Meent writes:
> > I noticed the only changes here are for `static` definitions. Are we
> > just more careful with normal functions, or does the compiler complain
> > more easily about such "incomplete" definitions whe
Hi,
On 2025-11-28 16:41:46 +1300, Thomas Munro wrote:
> 0001: These days we handle LLVM API evolution with LLVM_VERSION_MAJOR
> guards. These GDB and Perf support probes escaped recent garbage
> collection cycles by not being phrased like that. Function probes are
> generally better for cross-
On 2025-12-02 Tu 6:31 PM, Chao Li wrote:
On Dec 3, 2025, at 07:13, Tom Lane wrote:
Chao Li writes:
On Dec 3, 2025, at 06:51, Tom Lane wrote:
In this case, I think pgindent is indirectly enforcing good style.
I do not like omitting braces around anything that's more than one
line; readers hav
Hi,
On 2025-12-02 13:10:29 +0900, Amit Langote wrote:
> On Fri, Nov 21, 2025 at 8:45 PM Rahila Syed wrote:
> >
> > 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 fa
Tomas Vondra writes:
> On 12/2/25 17:05, Tomas Vondra wrote:
>> So it was ~19h for a while (started at ~14h about 4y back). And then
>> between September 14 and 22 it jumped to ~32h. Which seems like a lot.
> After bisecting this, it seems to have changed in this commit:
> commit 1eccb93150707ac
Hi,
On 03/12/2025 03:08, Peter Geoghegan wrote:
Coming back to this patch now, after several months of work on index
prefetching.
Nice, welcome back! It would be great to wrap this up.
Tomas Vondra suggested that I keep killedItems as a separate
allocation (as it is on master), while using a
ср, 3 дек. 2025 г. в 06:09, Peter Geoghegan :
> Coming back to this patch now, after several months of work on index
> prefetching.
>
> I decided that it wasn't such a great idea to reuse/steal an unused
> "itemDead" bit from the BTScanPosItem.itemOffset field after all. That
> forces _bt_killitem
Hi,
On 2025-12-03 10:28:36 +0800, Chao Li wrote:
> I know -Wshadow=compatible-local is not supported by all compilers, some
> compilers may fallback to -Wshadow and some may just ignore it. This patch
> set has cleaned up all shadow-variable warnings, once the cleanup is done,
> in theory, we shou
Matthias van de Meent writes:
> I noticed the only changes here are for `static` definitions. Are we
> just more careful with normal functions, or does the compiler complain
> more easily about such "incomplete" definitions when they're in
> headers or need to be linked against?
Some years ago we
Ashutosh Bapat writes:
> Adding a feature which allows a system to run with compromisable
> superuser credentials doesn't seem like something the community
> usually accepts.
Ashutosh,
I think there’s a misunderstanding. This doesn’t "allow" running with weak
superuser creds; it’s a hardening to
Hi,
On 2025-12-03 08:14:41 +, Bertrand Drouvot wrote:
> On Tue, Dec 02, 2025 at 03:00:39PM -0500, Andres Freund wrote:
> > On 2025-12-02 07:40:44 +, Bertrand Drouvot wrote:
> > > From 2fefb69f1462ce1057bb5c3d07ed70c769ec961a Mon Sep 17 00:00:00 2001
> > > From: Bertrand Drouvot
> > > Date
On Wed, 3 Dec 2025 at 15:51, Bertrand Drouvot
wrote:
>
> Hi hackers,
>
> In C standards till C17, func() means "unspecified parameters" while
> func(void)
> means "no parameters". The former disables compile time type checking and was
> marked obsolescent in C99 ([1]).
>
> This patch replaces emp
Ignat Remizov writes:
> pg_execute_server_program is sufficient for non‑superusers, but superusers
> always bypass it. In the incident that prompted this, the attacker obtained
> superuser via weak/default creds on an exposed instance (common in shared
> dev
> or staging setups). From there, COPY
Hi hackers,
In C standards till C17, func() means "unspecified parameters" while func(void)
means "no parameters". The former disables compile time type checking and was
marked obsolescent in C99 ([1]).
This patch replaces empty parameter lists with explicit void to enable proper
type checking an
On Wed, Dec 3, 2025 at 6:07 PM Ignat Remizov wrote:
>
> Thanks for looking, Ashutosh.
>
> pg_execute_server_program is sufficient for non‑superusers, but superusers
> always bypass it. In the incident that prompted this, the attacker obtained
> superuser via weak/default creds on an exposed instan
On 2025-Dec-01, Amit Kapila wrote:
> The reason for displaying in this style is that, in conflicts, users
> may want to define their custom resolution strategies based on
> conflict_type. Sometimes they need to resolve conflicts manually as
> well. To make an informed decision on which version of
On 2025-Dec-03, Chao Li wrote:
> Unfortunately that doesn’t work for my compiler (clang on MacOS),
> that’s why I renamed “I" to “u”.
I think you're missing his point. He's suggesting to change not only
this variable, but also the other uses of "i" in this function.
I'd also change "unsigned" t
On 12/2/25 17:05, Tomas Vondra wrote:
> ...
>
> So it was ~19h for a while (started at ~14h about 4y back). And then
> between September 14 and 22 it jumped to ~32h. Which seems like a lot.
>
> And that seems to be due to stats_ext changing from
>
> ok 157 + stats_ext
On 2025-Dec-03, Mihail Nikalayeu wrote:
> Oh, my bad, sorry.
> Attached patch with output variant for
> RELCACHE_FORCE_RELEASE\CATCACHE_FORCE_RELEASE case.
Thanks.
> But for CLOBBER_CACHE_ALWAYS - it is just a mess, too many different
> kinds of wakeup loops need to be done.
Hmm, maybe we can d
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 the REL_18_1 tag (with applying
v15-pg18-0001-Set-next-multixid-s-offset-when-creating-a-.pa
On Wed, Dec 3, 2025 at 6:03 AM David Geier wrote:
> I'm wondering how to best do a GUC for something that is potentially
> unavailable on the system. In that case the GUC would be superfluous.
> Maybe a boolean "enable_try_fast_clocksource" GUC or a "clocksource"
> enum GUC which can be "default"
On Wed, Dec 3, 2025 at 12:11 AM Michael Paquier wrote:
> Robert, does this line of arguments address the concerns you had
> upthread? Or do you still see a reason why not cleaning up these
> recovery parameters would not be a good idea?
>
> I don't see a strong need for a backpatch here as the ap
1 - 100 of 131 matches
Mail list logo
