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
> src/test/recovery/t/027_stream_regress.pl. It seems wasteful to read
> the file again twice in read_file_ends(). Alternativ
On Thu, 4 Dec 2025 at 03:56, Masahiko Sawada wrote:
> The proposed patch requires us to create one function per option. I'm
> concerned that it could cause bloating functions and be overkill just
> to save changing a separate list. I would suggest starting with
> putting a validation check for op
On Thu, Dec 04, 2025 at 08:52:16AM +0800, WangYu wrote:
> 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.
Please be careful that the mailing
Updated patch attached.
0001-Show-PG-version-in-pg_upgrade-test-log.patch
Description: Binary data
> Indeed. It looks like this should be backpatched down to v15 for two
> reasons: Cluster.pm exists since v15 and pg_upgrade has been converted
> to TAP since v15.
I rebased the patch to be up-to-date with master.
--
Alexander
Hi,
On Sat, 29 Nov 2025 at 14:07, Miłosz Bieniek wrote:
>
> pt., 28 lis 2025 o 16:17 Nazir Bilal Yavuz napisał(a):
> >
> > Hi,
> >
> > On Fri, 28 Nov 2025 at 18:05, Nazir Bilal Yavuz wrote:
> > >
> > > On Fri, 28 Nov 2025 at 17:03, Miłosz Bieniek
> > > wrote:
> > > >
> > > > pt., 28 lis 2025
Hi. Some review comments for v9-0001.
==
Commit message.
1.
Note: A single remote tuple may conflict with multiple local conflict
when conflict type
is CT_MULTIPLE_UNIQUE_CONFLICTS, so for handling this case we create a
single row in
conflict log table with respect to each remote conflict row
Hi Michael,
Regarding the function regression_log_helper(), this function reads all the
lines in the logs at line 219 of src/test/recovery/t/027_stream_regress.pl. It
seems wasteful to read the file again twice in read_file_ends(). Alternatively,
we could read the file once within regression_lo
On Thu, 4 Dec 2025 at 11:37, Nitin Jadhav wrote:
>
> Apologies, I missed attaching the patch earlier. Please find the v2
> version attached.
>
> Best Regards,
> Nitin Jadhav
> Azure Database for PostgreSQL
> Microsoft
>
> On Thu, Dec 4, 2025 at 12:01 PM Nitin Jadhav
> wrote:
> >
> > The patch was
On Fri, Nov 7, 2025 at 7:29 AM Robert Treat wrote:
>
> > Hi!
> > I looked at v3.
> >
> > Should we rename `ATExecAlterConstrEnforceability` to
> > `ATExecAlterFKConstrEnforceability `?
> >
>
> +1
>
> Robert Treat
> https://xzilla.net
hi.
AlterConstrEnforceabilityRecurse renamed to
AlterFKConstrE
On Wed, Dec 3, 2025 at 4:57 PM Dilip Kumar wrote:
>
> >
> > Thanks, it looks good. For the benefit of others, could you include a
> > brief note, perhaps in the commit message for now, describing how to
> > access or read this array column? We can remove it later.
>
> Thanks, okay, temporarily I h
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 invalidation cannot occur when copying because:
> > >
> > > Currently, there are
Apologies, I missed attaching the patch earlier. Please find the v2
version attached.
Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft
On Thu, Dec 4, 2025 at 12:01 PM Nitin Jadhav
wrote:
>
> The patch wasn’t applying cleanly on master, so I’ve rebased it and
> also added it to
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:
> > >
> > > Hi,
> > >
> > > On Fri, Nov 28, 2025 at 03:30:48PM +0530, Amit Kapila wrote:
> > > > I suggested the current one because
The patch wasn’t applying cleanly on master, so I’ve rebased it and
also added it to the PG19‑4 CommitFest:
https://commitfest.postgresql.org/patch/6279/
Please review and share your feedback.
Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft
Best Regards,
Nitin Jadhav
Azure Data
On Wed, Dec 3, 2025 at 11:34 PM Mihail Nikalayeu
wrote:
>
> 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
On Wed, Dec 3, 2025 at 8:11 PM Álvaro Herrera wrote:
>
> 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 manu
Hi,
I summarized the number of comparisons needed for different 'k':
k = 2, heap: 1, loser tree: 1
k = 3, heap: 2, loser tree: [1, 2]
k = 4, heap: [2, 3], loser tree: 2
k = 5, heap: [2, 4], loser tree: [2, 3]
So if k < 5, the loser tree is never worse than the heap for any input data.
Thoughts
On Thu, Dec 4, 2025 at 10:51 AM Ajin Cherian wrote:
>
> On Wed, Dec 3, 2025 at 10:19 PM Amit Kapila wrote:
> >
> > On Wed, Dec 3, 2025 at 8:51 AM Ajin Cherian wrote:
> > >
> > > Attaching patch v28 addressing these comments.
> > >
> >
> > Can we extract the part of the patch that handles SIGUSR1
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 invalidation cannot occur when copying because:
> >
> > Currently, there are no CHECK_FOR_INTERRUPTS() calls between the initial
> > restart_lsn copy (first
Hi Peter,
On Mon, Dec 1, 2025 at 10:24 AM Peter Geoghegan wrote:
> On Mon, Nov 10, 2025 at 6:59 PM Peter Geoghegan wrote:
> > The new tentative plan is to cut scope by focussing on switching over
> > to the new index AM + table AM interface from the patch in the short
> > term, for Postgres 19.
On Wed, Dec 03, 2025 at 09:11:03AM -0500, Greg Burd wrote:
> On Dec 2 2025, at 11:16 pm, Michael Paquier wrote:
> I've looked in the email archives a bit and didn't come up with much
> related to catalog upgrades. I don't know if there is much on the
> record information on this idea, but from wh
I wrote:
> Adding to my confusion, I do not see these warnings on a local
> RHEL9 machine, which ought to be pretty equivalent to CentOS 9.
Oh! I see part of the story: I was testing that with gcc.
If I switch to clang (version 20.1.8 here), then I see that
we pick "__syslog__" and then these com
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, int level, Tuplesortstate
> *state)
> +{
> + RadixPart
On Wed, Dec 3, 2025 at 10:19 PM Amit Kapila wrote:
>
> On Wed, Dec 3, 2025 at 8:51 AM Ajin Cherian wrote:
> >
> > Attaching patch v28 addressing these comments.
> >
>
> Can we extract the part of the patch that handles SIGUSR1 signal
> separately as a first patch and the remaining as a second pat
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=]
234 | #define pg_att
On Thu, Dec 4, 2025 at 7:31 AM Masahiko Sawada wrote:
>
> 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
> > > > conflic
Hi all,
Thank you for the review and kind feedback.
On Mon, Dec 1, 2025 at 1:45 PM Michael Banck wrote:
>
> Hi,
>
> On Mon, Dec 01, 2025 at 11:05:19AM +0530, Soumya S Murali wrote:
> > > On Fri, Nov 28, 2025 at 10:23:54AM +0530, Soumya S Murali wrote:
> > > I am still not convinced of the useful
Hi Melanie,
I resisted this patch again today. I reviewed 0001-0004, and got a few more
comments:
> On Dec 4, 2025, at 07:07, Melanie Plageman wrote:
>
>
1 - 0002
```
+static bool
+heap_page_will_set_vis(Relation relation,
+ BlockNumber heap_blk,
+
On Thu, Dec 4, 2025 at 1:14 AM Sami Imseih wrote:
> 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.
It's happened multiple times before that someone proposes
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
1 - 100 of 161 matches
Mail list logo
