On 07.11.25 16:14, Tom Lane wrote:
Peter Eisentraut writes:
Here are a few more small patches to fix related things I found
afterwards or in passing.
Looks sane, except that the comparator could do with an extra "const"
if there's enough room on the line:
+const struct config_generic *ca
As noted in the commit message of 66e9df9f6, we can now safely use
NRM_EQUAL to process NestLoopParams in setrefs.c. This is because
identify_current_nestloop_params now ensures that Vars or PHVs seen in
a NestLoopParam expression have nullingrels that include exactly the
outer-join relids that ap
> On Nov 10, 2025, at 21:48, Mario González Troncoso
> wrote:
>
> Hey there,
>
> Based on the Alvaro's idea [1] about moving different instrumentation
> related C structures and enums into one single header file, I'm
> sending the following patches.
> That single file is named `executor/inst
On Wed, Nov 5, 2025 at 2:31 AM Tom Lane wrote:
>
>
> If it actually matters for DROP EXPRESSION, then the answer is
> probably "we can't use ATSimpleRecursion for DROP EXPRESSION".
> ATSimpleRecursion is meant for cases where each table can be
> processed independently, regardless of its position
> On Nov 10, 2025, at 17:28, Aleksander Alekseev
> wrote:
>
>> 1. I just ran the patched pgindent against a random file, then I got a lot
>> diffs like:
>>
>> ```
>>/*
>> -* Direct advancement: avoid waking non-caught up backends that
>> -* aren't interested in our n
> On Nov 10, 2025, at 22:43, Daniel Gustafsson wrote:
>
>> On 10 Nov 2025, at 10:06, Chao Li wrote:
>>> On Nov 8, 2025, at 14:25, Sugamoto Shinya wrote:
>
>>> This patch adds an error hint listing the valid encoding names,
>>> so users can immediately see the supported options.
>
> +1.
>
On Thu, 6 Nov 2025 at 11:03, Mahendra Singh Thalor wrote:
>
> Thanks Vaibhav, Tushar and Andrew for the review and testing.
>
> On Mon, 3 Nov 2025 at 17:30, Vaibhav Dalvi
> wrote:
> >
> > Hi Mahendra,
> >
> > I have a few more review comments regarding the patch:
> >
> > 1. Is the following chang
> On Nov 4, 2025, at 09:43, Peter Smith wrote:
>
> On Wed, Oct 29, 2025 at 8:10 PM Chao Li wrote:
> ...
>> I think 0001 basically good. A tiny comment is that, in inval.c,
>> "wal_level>=logical” doesn’t have white-spaces around “=“, while in the
>> other two files, they have. So maybe all
hashbuild() says:
* If we just insert the tuples into the index in scan order, then
* (assuming their hash codes are pretty random) there will be no locality
* of access to the index, and if the index is bigger than available RAM
* then we'll thrash horribly. To prevent that scenario, we can
Hi Vignesh,
A few more comments:
> On Nov 7, 2025, at 22:47, vignesh C wrote:
>
> The attached v20251107_2 version patch has the changes for the same.
>
> Regards,
> Vignesh
>
1
```
-Currently, there can be only one synchronization worker per table.
+Currently, there can be o
Hi Alvaro,
Thanks for the explanation.
I tried to get rid of String usage in 0001 patch.
Prepared 0002 patch for actual implementation of the
function p_get_subscription_ddl().
Please find attached patches.
Regards,
Vaibhav
On Fri, Nov 7, 2025 at 5:41 PM Álvaro Herrera wrote:
> On 2025-Nov-0
On Tue, 11 Nov 2025 at 09:59, Shlok Kyal wrote:
>
> On Tue, 11 Nov 2025 at 09:02, Amit Kapila wrote:
> >
> > On Mon, Nov 10, 2025 at 4:22 PM vignesh C wrote:
> > >
> > > On Mon, 10 Nov 2025 at 14:34, Shlok Kyal wrote:
> > > >
> > > > While working on another thread, I found that in HEAD gram.y
Fujii Masao writes:
> To address this, callers need a way to distinguish between PGRES_FATAL_ERROR
> and OOM. Functions that loop until PQgetResult() returns NULL should continue
> if the result is PGRES_FATAL_ERROR, but should break if it's an OOM.
Not sure about that. We might or might not be
On Tue, Nov 11, 2025 at 12:59 PM Tom Lane wrote:
> Thomas Munro writes:
> > I think the incorrect spelling fits the usual pattern (movable,
> > valuable, believable, ... with moveable accepted but dying), and it's
> > definitely "caching" without the -e-, so it's probably a tempting
> > mistake
On Tue, Nov 11, 2025 at 12:12 PM Chao Li wrote:
> For example, pgbench:
>
> * When pgbench calls readCommandResponse()
> * If OOM happens, PQgetResult() returns OOM_reslt whose resultState is
> PGRES_FATAL_ERROR
> * readCommandResponse() will goto the error tag, then
> discardAvailableResults()
I'm going to build psqlODBC (Arm64X binaries) for use with Windows 11 on
Arm.
The problem is that the `msvc_gendef.pl` generates the wrong `postgres.def`
for aarch64 (Windows).
Currently, for aarch64, the preceding underscore is removed like for x86.
However, the expected functionality for aarch6
Thomas Munro writes:
> I think the incorrect spelling fits the usual pattern (movable,
> valuable, believable, ... with moveable accepted but dying), and it's
> definitely "caching" without the -e-, so it's probably a tempting
> mistake to make, but apparently we're making new words out of bits of
On Tue, Nov 11, 2025 at 4:45 PM Peter Smith wrote:
> IMO it's a typo. The correct spelling is "cacheable", so it should be
> corrected where you reported and also in the other two places.
+1
I think the incorrect spelling fits the usual pattern (movable,
valuable, believable, ... with moveable a
>
> As mentioned before, to make
> CAST(source_expr AS target_type DEFAULT expr ON CONVERSION ERROR);
> work,
> we cannot just simply replace casting FuncExpr nodes with CoerceViaIO,
> since
> type modifiers behave differently in these two Nodes.
> (e.g., casting numeric 1.11 to integer is not equi
On Tue, 11 Nov 2025 at 09:02, Amit Kapila wrote:
>
> On Mon, Nov 10, 2025 at 4:22 PM vignesh C wrote:
> >
> > On Mon, 10 Nov 2025 at 14:34, Shlok Kyal wrote:
> > >
> > > While working on another thread, I found that in HEAD gram.y has
> > > grammar which was committed as part of this thread:
> >
On Thu, Nov 6, 2025 at 4:32 AM Masahiko Sawada wrote:
>
>
> I've updated and rebased the patch.
>
Thanks for the patch. Please find a few comments:
1)
ReplicationSlotsDropDBSlots:
+ SpinLockAcquire(&s->mutex);
+ invalidated = s->data.invalidated == RS_INVAL_NONE;
+ SpinLockRelease(&s->mutex);
Dear Amit,
> We need to check whether a similar change is required in
> reserve_wal_for_local_slot() as well for sync slots.
Good point. I confirmed similar issue could happen while synchronizing slots.
PSA the reproducer.
0001-PG17... patch simulates the issue that WAL segments were discarded
On Tue, Nov 11, 2025 at 2:33 PM Chao Li wrote:
>
> Hi Hacker,
>
> While working on the other patch and editing heapam.c, I noticed this in line
> 2251:
> ```
> /*
> * If tuple is cachable, mark it for invalidation from the caches in case
> * we abort. Note it is OK to do this after releasing
On Tue, Nov 11, 2025 at 2:19 PM Amit Kapila wrote:
>
> In the commit message, you mentioned: "Performance tests show it's
> faster than the COPY (SELECT ...) TO variant as it avoids the
> overheads of query processing and sending results to the COPY TO
> command.". Can you share the performance da
Dear Amit, Alexander,
> The fix seems to be only provided for bank branches, but IIUC the
> problem can happen in HEAD as well.
Yes, I confirmed this can happen. [1] can be applied atop HEAD and
reproduce the invalidation.
> In Head, how about acquiring
> ReplicationSlotAllocationLock in Exclusi
Hi Hacker,
While working on the other patch and editing heapam.c, I noticed this in line
2251:
```
/*
* If tuple is cachable, mark it for invalidation from the caches in case
* we abort. Note it is OK to do this after releasing the buffer, because
* the heaptup data structure is all in local
On Mon, Nov 10, 2025 at 4:22 PM vignesh C wrote:
>
> On Mon, 10 Nov 2025 at 14:34, Shlok Kyal wrote:
> >
> > While working on another thread, I found that in HEAD gram.y has
> > grammar which was committed as part of this thread:
> > ```
> > | CREATE PUBLICATION name FOR pub_obj_type_
On Tue, Nov 11, 2025 at 8:39 AM Ajin Cherian wrote:
>
> After patch [1] was committed, the COPY TO command is now supported
> for partitioned tables. This change updates the tablesync logic to use
> COPY TO for partitioned tables as well.
>
In the commit message, you mentioned: "Performance tests
> On Nov 11, 2025, at 01:07, Yugo Nagata wrote:
>
> Hi,
>
> Currently, PQgetResult() returns NULL not only when no results remain for
> a sent query, but also when an out-of-memory error occurs, except when
> PGconn itself is NULL. As a result, users cannot distinguish between query
> complet
Hi all,
After patch [1] was committed, the COPY TO command is now supported
for partitioned tables. This change updates the tablesync logic to use
COPY TO for partitioned tables as well. This change will only be
invoked when the publication is configured with
publish_via_partition_root = true;
oth
On Mon, Nov 10, 2025 at 2:41 PM Amit Kapila wrote:
>
> On Wed, Nov 5, 2025 at 3:48 PM Alexander Korotkov
> wrote:
> >
> > On Mon, Oct 6, 2025 at 6:46 PM Vitaly Davydov
> > wrote:
> > > There is one subtle thing. Once, the operation of restart_lsn assignment
> > > is not
> > > an atomic, the f
> On Nov 10, 2025, at 12:45, Fujii Masao wrote:
>
> On Mon, Nov 10, 2025 at 11:07 AM Chao Li wrote:
>> I just did a test. In the test, I inserted a tuple with the same primary key
>> so that the inserts fails by the unique key constraint which breaks the
>> pipeline, and some random select
> On Nov 11, 2025, at 09:50, Yugo Nagata wrote:
>
> On Fri, 7 Nov 2025 18:33:17 +0900
> Fujii Masao wrote:
>
>> I plan to commit the patch soon, but let's keep discussing and
>> investigating the case you mentioned afterward!
>
> I'm sorry for the late reply and for not joining the discussi
Hi Michael,
I am just getting started in the Postgres community (this is my first code
review). So please excuse me if I have missed something (in terms of process
etc).
I reviewed your proposed code changes in the attached patch file and they look
good to me. I have some minor comments:
1. In
On Mon, Nov 10, 2025 at 05:21:00PM -0800, Joshua Shanks wrote:
> You're absolutely right, thank you for catching that! I was
> double-wrapping the translation.
>
> libpq_append_conn_error() already calls libpq_gettext()
> internally (fe-misc.c:1420), so these changes are unnecessary. I'm
> withdra
On 11/10/25 4:47 PM, Nathan Bossart wrote:
On Mon, Nov 10, 2025 at 04:40:57PM -0500, Tom Lane wrote:
Nathan Bossart writes:
On Mon, Nov 10, 2025 at 02:01:14PM -0500, Jonathan S. Katz wrote:
If you previously created a BRIN index using the `numeric_minmax_multi_ops`
operator class, please see
On Fri, 7 Nov 2025 18:33:17 +0900
Fujii Masao wrote:
> I plan to commit the patch soon, but let's keep discussing and
> investigating the case you mentioned afterward!
I'm sorry for the late reply and for not joining the discussion earlier.
I've spent some time investigating the code in pgbench
On Mon, Nov 10, 2025 at 04:31:07PM +0100, Andrei Lepikhov wrote:
> In multimaster, you may find an implementation of strictly monotone
> sequences. This method is covered by a GUC, impolitely named as 'Volkswagen
> method'.
I'm afraid that I cannot understand what you mean with this reference.
>
You're absolutely right, thank you for catching that! I was
double-wrapping the translation.
libpq_append_conn_error() already calls libpq_gettext()
internally (fe-misc.c:1420), so these changes are unnecessary. I'm
withdrawing this patch.
On Sun, Nov 9, 2025 at 11:04 PM Fujii Masao wrote:
> On
On Sat, 8 Nov 2025 at 08:23, Sami Imseih wrote:
> > I'm confused at why we'd have set up our autovacuum trigger points as
> > they are today because we think those are good times to do a
> > vacuum/analyze, but then prioritise on something completely different.
> > Surely if we think 20% dead tupl
> On Nov 10, 2025, at 22:56, Xuneng Zhou wrote:
>
> Hi hackers,
>
> /*
> * Sequential: Issue advice until the preadv() calls have caught
> * up with the first advice issued for this sequential region, and
> * then stay of the way of the kernel's own read-ahead.
> */
>
> “out” is missing from
On Sun, Nov 2, 2025 at 6:49 PM Peter Geoghegan wrote:
> Nothing really new here (I've been
> working on batching on the table AM side, but nothing to show on that
> just yet).
Tomas and I had a meeting on Friday to discuss a way forward with this
project. Progress has stalled, and we feel that no
On Mon, Nov 10, 2025 at 06:27:41PM +0800, Xuneng Zhou wrote:
> Thanks for the patch. I also agree with Chao's suggestion that the
> error message better reflects the actual character limits. I
> implemented a patch for that and updated the test patch as well.
> Please check.
Yes, that works here.
On Mon, Nov 10, 2025 at 04:28:02PM -0500, Tom Lane wrote:
> Robert Haas writes:
>> This patch doesn't look well-considered to me. One problem is that
>> it's a wire protocol change to fix a minor logging anomaly, which
>> seems disproportionate. Another problem is that the new portal-drop
>> behav
On Mon, Nov 10, 2025 at 01:56:23PM -0600, Sami Imseih wrote:
> I started reworking the patch, but then I realized that I don't like this
> approach of using the same callback to support serializing NameData and
> serializing extra data. In the existing "to_serialized_name" callback
> , NameData is
On Mon, Nov 10, 2025 at 12:05 PM Nathan Bossart
wrote:
>
> On Mon, Nov 10, 2025 at 10:49:58AM -0600, Nathan Bossart wrote:
> > On Mon, Nov 10, 2025 at 10:26:17AM -0600, Nathan Bossart wrote:
> >> It's probably a good idea to avoid tranche leaks, but IMHO there's room for
> >> improvement in the DS
Hi,
On Mon, Nov 10, 2025 at 07:48:03PM -0300, Matheus Alcantara wrote:
> On Mon Nov 10, 2025 at 3:25 PM -03, Manni Wood wrote:
> > I have a small bikeshedding comment around making "location" the 4th column
> > returned for "select * from pg_available_extensions", as opposed to leaving
> > "commen
Thank you for reviewing this!
On Mon Nov 10, 2025 at 3:25 PM -03, Manni Wood wrote:
> Hello!
>
> I have a small bikeshedding comment around making "location" the 4th column
> returned for "select * from pg_available_extensions", as opposed to leaving
> "comment" the 4th column returned for "select
>
>
> My attempts to test this all got stuck in wait_on_slots(). I haven't
> looked too closely, but I suspect the issue is that the socket never
> becomes readable because we don't send a query. If I set free_slot->inUse
> to false before printing the command, it no longer hangs. We probably wa
Attached is a cleaned up rebase with improved memory handling, additional code
documentation, removed passphrase test (sent as a separate thread), and some
general cleanup and additional testing.
--
Daniel Gustafsson
v9-0001-Serverside-SNI-support-for-libpq.patch
Description: Binary data
Replying to Michael's message:
https://www.postgresql.org/message-id/68adbcd3.500a0220.8d4c9.9460%40mx.google.com
Sorry I missed this. I had some trouble with your messages being
deleted as spam, which I've hopefully fixed now...
-#elif defined(__linux__) || defined(__sun) || defined(__darwin__
Hi,
On Tue, Nov 11, 2025 at 09:03:32AM +1300, Thomas Munro wrote:
> Interesting. Perhaps a minimal program that installs a handler
> assert(signo < 32) for both SIGUSR1 and SIGUSR2 might fail too, if
> another program loops calling kill(the_other_one, rand() % 2 == 0 ?
> SIGUSR1 : SIGUSR2), to su
On Mon, Nov 10, 2025 at 04:40:57PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> On Mon, Nov 10, 2025 at 02:01:14PM -0500, Jonathan S. Katz wrote:
>>> If you previously created a BRIN index using the `numeric_minmax_multi_ops`
>>> operator class, please see the "Updating" section for addition
Nathan Bossart writes:
> On Mon, Nov 10, 2025 at 02:01:14PM -0500, Jonathan S. Katz wrote:
>> If you previously created a BRIN index using the `numeric_minmax_multi_ops`
>> operator class, please see the "Updating" section for additional instructions
>> after upgrading your instance.
> It looks l
On Mon, Nov 10, 2025 at 02:01:14PM -0500, Jonathan S. Katz wrote:
> If you previously created a BRIN index using the `numeric_minmax_multi_ops`
> operator class, please see the "Updating" section for additional instructions
> after upgrading your instance.
It looks like these additional instructio
Nathan Bossart writes:
> FWIW something I am hearing about more often these days, and what I believe
> Maxim's patch is actually after, is the 1GB limit on row size. Even if
> each field doesn't exceed 1GB (which is what artifacts.md seems to
> demonstrate), heap_form_tuple() and friends can fail
Robert Haas writes:
> On Wed, Nov 5, 2025 at 12:43 AM Michael Paquier wrote:
>> Drop unnamed portal immediately after execution to completion
> This patch doesn't look well-considered to me. One problem is that
> it's a wire protocol change to fix a minor logging anomaly, which
> seems dispropor
On Mon, Nov 10, 2025 at 02:44:41PM -0500, Corey Huinker wrote:
> This is a small patch to add a new option to vacuumdb to answer the
> question "what commands will actually be run by this combination of
> command-line switches against this database?" without actually running the
> commands.
My att
On Wed, Nov 5, 2025 at 12:43 AM Michael Paquier wrote:
> Drop unnamed portal immediately after execution to completion
This patch doesn't look well-considered to me. One problem is that
it's a wire protocol change to fix a minor logging anomaly, which
seems disproportionate. Another problem is th
10.11.2025 22:03, Thomas Munro wrote:
On Tue, Nov 11, 2025 at 8:00 AM Alexander Lakhin wrote:
With this modification:
@@ -137,7 +140,7 @@ pqsignal(int signo, pqsigfunc func)
#if !(defined(WIN32) && defined(FRONTEND))
act.sa_handler = func;
- sigemptyset(&act.sa_mask);
+
On Mon, 2025-11-03 at 20:14 +0100, Daniel Verite wrote:
> No, I think we should put the database's lc_ctype
> into LC_CTYPE and the database's lc_collate into
> LC_COLLATE, independently of anything else,
> like it was done until commit 5e6e42e.
> I believe that's the purpose of these database
> pr
On Fri, Nov 07, 2025 at 09:32:45PM -0500, Tom Lane wrote:
> Maxim Zibitsker writes:
>> PostgreSQL's MaxAllocSize limit prevents storing individual
>> variable-length character strings exceeding ~1GB, causing "invalid
>> memory alloc request size" errors during INSERT operations on tables
>> with l
On Tue, Nov 11, 2025 at 9:03 AM Thomas Munro wrote:
> Interesting. Perhaps a minimal program that installs a handler
> assert(signo < 32) for both SIGUSR1 and SIGUSR2 might fail too, if
Or tighter: assert(signo == SIGUSR1 || signo == SIGUSR2).
On Tue, Nov 11, 2025 at 4:19 AM Tom Lane wrote:
> Heikki Linnakangas writes:
> > The patch removes 'src/template/solaris'. Is that on purpose? Is that an
> > independent cleanup that could be committed immediately?
>
> Our four Solaris+illumos buildfarm animals would be sad.
Looks like I overdid
On Tue, Nov 11, 2025 at 8:00 AM Alexander Lakhin wrote:
> With this modification:
> @@ -137,7 +140,7 @@ pqsignal(int signo, pqsigfunc func)
>
> #if !(defined(WIN32) && defined(FRONTEND))
> act.sa_handler = func;
> - sigemptyset(&act.sa_mask);
> + sigfillset(&act.sa_mask);
>
While working on my autovacuum scheduling patch [0], I noticed the
following comment in relation_needs_vacanalyze():
/*
* Note that we don't need to take special consideration for stat
* reset, because if that happens, the last vacuum and analyze counts
* will be
10.11.2025 21:33, Michael Banck wrote:
On Mon, Nov 10, 2025 at 09:00:01PM +0200, Alexander Lakhin wrote:
I got 100 iterations passed (12 of them hanged) without that Assert
triggered.
But those hangs were unrelated to the assert then, right?
Yeah, I think there are several unrelated issues he
> > Hmm. I would like to propose something a bit more flexible,
> > refactoring and reusing some of the existing callbacks, among the
> > following lines:
> > - Rather than introducing a second callback able to do more
> > serialization work, let's expand a bit the responsibility of
> > to_seriali
This is a small patch to add a new option to vacuumdb to answer the
question "what commands will actually be run by this combination of
command-line switches against this database?" without actually running the
commands.
Including Nathan because we had previously discussed the utility of just
such
Hi Alexander,
On Mon, Nov 10, 2025 at 09:00:01PM +0200, Alexander Lakhin wrote:
> Sorry for the delay. I've finally completed a new round of experiments and
> discovered the following:
[...]
> 12.10.2025 03:42, Thomas Munro wrote:
> > * I wonder about the special code paths for handlers that we
Hello,
On Sun, Aug 31, 2025 at 4:16 PM Andrey Borodin wrote:
>
>
> > On 29 Aug 2025, at 13:39, Andrey Borodin wrote:
> >
>
> What if we just abort a scan, that stepped on the page where tuples were
> moved out?
>
...
> What do you think?
>
We have a database on which we have bulk insertions a
Hi,
Attached is a draft of the 2025-11-13 release announcement. Please
provide feedback on correctness, notable omissions no later than
2025-11-13 12:00 UTC (and ideally earlier!)
Thanks!
Jonathan
The PostgreSQL Global Development Group has released an update to all
supported versions of Pos
On Thu, Nov 6, 2025 at 9:29 AM Matheus Alcantara
wrote:
> Thanks for reviewing this!
>
> On Sun Nov 2, 2025 at 12:11 PM -03, Michael Banck wrote:
> > On Mon, Sep 15, 2025 at 09:18:25PM -0300, Matheus Alcantara wrote:
> >> postgres=# select * from pg_available_extensions;
> >> name | default_v
On Mon, Nov 10, 2025 at 10:49:58AM -0600, Nathan Bossart wrote:
> On Mon, Nov 10, 2025 at 10:26:17AM -0600, Nathan Bossart wrote:
>> It's probably a good idea to avoid tranche leaks, but IMHO there's room for
>> improvement in the DSM registry, too. IIUC the problem is that the DSM
>> segment is s
On 10/11/2025 18:38, Heikki Linnakangas wrote:
On 10/11/2025 17:16, Tom Lane wrote:
Heikki Linnakangas writes:
Committed. Thanks for the quick review!
I think the number this should have bumped is PG_CONTROL_VERSION
(thanks to the new field therein). Bumping CATALOG_VERSION_NO
seems quite b
Heikki Linnakangas writes:
> On 10/11/2025 17:16, Tom Lane wrote:
>> I think the number this should have bumped is PG_CONTROL_VERSION
>> (thanks to the new field therein). Bumping CATALOG_VERSION_NO
>> seems quite beside the point.
> Ah thanks, I forgot we have that as a separate version number.
Hi,
Currently, PQgetResult() returns NULL not only when no results remain for
a sent query, but also when an out-of-memory error occurs, except when
PGconn itself is NULL. As a result, users cannot distinguish between query
completion and an out-of-memory error when PQgetResult() returns NULL.
Th
Hi Peter,
>> Those changes to the meson.build files were not needed before
>> AIX support was removed. You should find a way to do it without these
>> changes.
The change was necessary to ensure that the import file used during the static
PostgreSQL library build begins with the required #! direc
Hi,
> Fixed all that, adjusted a few comments, then applied the result.
>
Thank you for making the fixes and committing the patch.
-Rahila Syed
On Mon, Nov 10, 2025 at 10:26:17AM -0600, Nathan Bossart wrote:
> On Mon, Nov 03, 2025 at 11:50:48AM -0600, Sami Imseih wrote:
I am not sure we need to do anything about this.
>>>
>>> Or maybe we just avoid the tranche_id from leaking
>>> in test_dsa_resowners() by making it a static variable
On 10/11/2025 17:16, Tom Lane wrote:
Heikki Linnakangas writes:
Committed. Thanks for the quick review!
I think the number this should have bumped is PG_CONTROL_VERSION
(thanks to the new field therein). Bumping CATALOG_VERSION_NO
seems quite beside the point.
Ah thanks, I forgot we have t
On Mon, Nov 03, 2025 at 11:50:48AM -0600, Sami Imseih wrote:
>>> I am not sure we need to do anything about this.
>>
>> Or maybe we just avoid the tranche_id from leaking
>> in test_dsa_resowners() by making it a static variable
>> and checking if we have a valid tranche id before calling
>> LWLock
On 10/11/2025 18:11, Andres Freund wrote:
Hi,
On 2025-11-10 13:29:08 +0200, Heikki Linnakangas wrote:
At the "make mxidoff 64 bits" thread [1], we're discussing moving
SLRU_PAGES_PER_SEGMENT to pg_config_manual.h, to make it accessible from
pg_upgrade code. It's currently defined in slru.h, whi
Hi~
We seem to have a reduntant initialization of rd_smgr for a newly created
relcache entry. Commonly, the pointer is assigned as NULL after a relcache
is palloc'ed. But this one seems unnecessary because the rd_smgr has already
been initialized by earlier AllocateRelationDesc. Propose a patch fo
Hi,
On 2025-11-10 13:29:08 +0200, Heikki Linnakangas wrote:
> At the "make mxidoff 64 bits" thread [1], we're discussing moving
> SLRU_PAGES_PER_SEGMENT to pg_config_manual.h, to make it accessible from
> pg_upgrade code. It's currently defined in slru.h, which cannot be included
> in frontend cod
On 08.11.25 22:40, Thomas Munro wrote:
Unfortunately
it didn't ever seem to become unbuildable, but apparently things break
in undiagnosed ways at runtime (at a guess it might have some API
calls that are stubbed out with empty implementations or something
like that, but there is zero reason to i
On 8/11/2025 00:02, Michael Paquier wrote:
On Fri, Nov 07, 2025 at 05:05:55PM +0100, Andrei Lepikhov wrote:
1. For pgEdge Snowflake, it would be really beneficial - there are not only
code copying issues, but also the Serial -> Snowflake conversion algorithm.
Additionally, for now, only an in-co
Heikki Linnakangas writes:
> The patch removes 'src/template/solaris'. Is that on purpose? Is that an
> independent cleanup that could be committed immediately?
Our four Solaris+illumos buildfarm animals would be sad.
regards, tom lane
Heikki Linnakangas writes:
> Committed. Thanks for the quick review!
I think the number this should have bumped is PG_CONTROL_VERSION
(thanks to the new field therein). Bumping CATALOG_VERSION_NO
seems quite beside the point.
regards, tom lane
Hi hackers,
/*
* Sequential: Issue advice until the preadv() calls have caught
* up with the first advice issued for this sequential region, and
* then stay of the way of the kernel's own read-ahead.
*/
“out” is missing from the phrase “stay of the way” in this comment.
This patch fixes it.
Best
On 11/9/25 19:42, Tom Lane wrote:
> Tomas Vondra writes:
>> If I set join_collapse_limit=1, then standard_join_search() only sees
>> problems of size 2, i.e. (list_length(initial_rels) == 2). And we only
>> look at has_join_restriction() *inside* these small problems, i.e. the
>> jointree must not
> On 10 Nov 2025, at 10:06, Chao Li wrote:
>> On Nov 8, 2025, at 14:25, Sugamoto Shinya wrote:
>> This patch adds an error hint listing the valid encoding names,
>> so users can immediately see the supported options.
+1.
> I think hardcoding the encoding list is fragile. AFAIK, “base64url” was
> On 10 Nov 2025, at 14:53, Chao Li wrote:
>> On Nov 10, 2025, at 19:04, zengman wrote:
>> When reviewing the postgresql.conf.sample file, I noticed that the range of
>> the commit_siblings parameter appears to have been incorrect for quite some
>> time. Attached is a simple patch to update it
Thanks for the detailed feedback!
On 04.11.2025 00:55, Tom Lane wrote:
Hmm. Those results sure look like there is a performance regression
up to at least 100 MCVs ... not a large one, but consistently a few
percent. That's a bit sad for a patch purporting to improve
performance. It looks to
On 10/11/2025 14:13, Álvaro Herrera wrote:
Seems reasonable to me.
Committed. Thanks for the quick review!
- Heikki
> On 10 Nov 2025, at 02:11, Michael Paquier wrote:
> While looking at a recent patch for injection points that has resulted
> in 16a2f706951e, I have been reminded that the point name, library
> name and function name have hardcoded limits, and it is now possible
> to have them tested by SQL.
Wh
On 10/11/2025 15:17, Thomas Munro wrote:
Hi,
Here is an experimental patch to try out standard C (and C++) atomics
to implement port/atomics.h, and also add more types and operations.
It's mostly just redirecting our names to the standard ones, except
for our barriers and slightly extended pg_at
> On Nov 10, 2025, at 19:04, zengman wrote:
>
> Hi, hackers
>
> When reviewing the postgresql.conf.sample file, I noticed that the range of
> the commit_siblings parameter appears to have been incorrect for quite some
> time. Attached is a simple patch to update it.
>
> --
> Regrads,
> Ma
Hey there,
Based on the Alvaro's idea [1] about moving different instrumentation
related C structures and enums into one single header file, I'm
sending the following patches.
That single file is named `executor/instrument_node.h`
Local tests and CI tests are passing
https://cirrus-ci.com/build/6
On Mon, Nov 10, 2025 at 5:27 AM Álvaro Herrera wrote:
> On 2025-Nov-08, Manni Wood wrote:
>
> > However, I see that this
> > https://cirrus-ci.com/task/6437176629526528?logs=clone#L214 checks out a
> > specific commit on a specific branch:
> >
> > "Checked out db131410131cb6a60f074213b0e715d7
1 - 100 of 136 matches
Mail list logo
