On Sun, 2025-11-16 at 17:45 +0100, Dmitry Dolgov wrote:
> Better late than never, rebased and dropped 0004.
I think that having a system view like that would be quite useful.
It would be even more useful if it included other libraries that are
optionally linked with PostgreSQL, like OpenSSL, OpenL
On Thu, Nov 20, 2025 at 4:44 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > On 19.11.25 04:15, Tom Lane wrote:
> >> I think we should do it
> >> honestly with a regression test. It doesn't need to be very
> >> complicated --- I think checking one message in one translation is
> >> sufficient,
On Wed, Nov 19, 2025 at 03:21:33PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > While working on a talk, I studied the number of code line changes in
> > each major release, and found PG 17 surprisingly reduced code line count
> > by 10%. To get the code line count, I used /pgtop/src/tools/c
Bruce Momjian writes:
> While working on a talk, I studied the number of code line changes in
> each major release, and found PG 17 surprisingly reduced code line count
> by 10%. To get the code line count, I used /pgtop/src/tools/codelines,
> which runs:
> find . -name '*.[chyl]' | xargs c
Sorry for the delay here.
v1 is the first attempt to address the feedback from the POC.
1/ A user is now able to register as many extra files as they
wish, and the files will be named pgstat...stat,
where file_no starts at 0 up to the number of files specified
by the user with .num_serialized_ext
On 11/19/25 13:28, David Geier wrote:
> On 18.11.2025 20:37, Tomas Vondra wrote:
>>
>>
>> On 11/18/25 19:35, David Geier wrote:
>>>
>>> On 18.11.2025 18:31, Tomas Vondra wrote:
On 11/18/25 17:51, Tom Lane wrote:
> David Geier writes:
>> On 18.11.2025 16:40, Tomas Vondra wrote:
While working on a talk, I studied the number of code line changes in
each major release, and found PG 17 surprisingly reduced code line count
by 10%. To get the code line count, I used /pgtop/src/tools/codelines,
which runs:
find . -name '*.[chyl]' | xargs cat| wc -l
Any ideas on the cau
On 19/11/2025 14:54, Fujii Masao wrote:
With the patch applied, these duplicate records no longer appear in
the pg_recvlogical output.
Thanks! Works like a charm. I confirm duplicates no longer appear with
the patch applied.
You can consider adding a test about this in "030_pg_recvlogical.p
On 19 Nov 2025 at 18:19 +0100, Dean Rasheed , wrote:
> On Wed, 19 Nov 2025 at 16:51, Viktor Holmberg wrote:
> >
> > For the CASE default, elog(ERROR, "unrecognized LockClauseStrength %d” that
> > was removed.
> > Would this now trigger a compile time error/warning? And are you supposed
> > to ge
On Thu, Nov 13, 2025 at 7:46 AM Alena Vinter wrote:
> Robert, here's a realistic scenario where the issue occurs:
> 1. Start with a primary and physical standby
> 2. Convert the standby to a logical replica using `pg_createsubscriber`
> 3. Later, create a new physical standby from a backup of this
On Wed, Nov 12, 2025 at 6:57 AM BharatDB wrote:
> Dear Evan and PostgreSQL community,
1. Please stop sending AI-generated emails and patches to this list.
If you want to use an AI tool to help you generate emails and patches,
that's fine with me. (I can't speak for anyone else.) But you're
clearl
On 6 Nov 2025 at 17:59 +0100, Álvaro Herrera , wrote:
> On 2025-Nov-06, Rafia Sabih wrote:
>
> > I am seeing following warning,
> >
> > In file included from specscanner.c:11:
> > In file included from ../../../src/include/postgres_fe.h:28:
> > ../../../src/include/c.h:113:9: warning: 'pg_restrict'
On Wed, Nov 19, 2025 at 11:55 AM Lukas Fittl wrote:
> Overall, I'm still thinking a GUC might be the way to go, but I don't think
> anyone else was enthusiastic about that idea :)
Reliable feature auto-detection is the best option, but if that's not
possible, I think the choices are add a GUC or
On 11/15/25 16:57, Tom Lane wrote:
> Nico Williams writes:
>> Some unsolicited advice:
>> ...
>> But here you can just use the order that the SQL uses. It gives the
>> author some power.
>
> If that's the approach you want, it's been possible for decades:
> "set join_collapse_limit = 1" and away
On Mon, Nov 3, 2025 at 8:53 AM Zsolt Parragi wrote:
> On Mon, Nov 3, 2025 at 4:25 PM Jacob Champion
> wrote:
> > The reason I ask is that we'd briefly talked about splitting
> > PGOAUTHDEBUG into more granular settings than just "off" and "UNSAFE".
>
> That's more similar to the direction I consi
On Wed, Nov 19, 2025 at 12:47 PM Bertrand Drouvot
wrote:
> > True, but if they write any new code, and care about it compiling with
> > older minor releases, this is a potential pitfall.
>
> Why given that 06edbed4786 has been back patched through 13?
I do not know how to make the phrase "older m
On Tue, 18 Nov 2025 at 09:50, Peter Eisentraut wrote:
>
> I want to discuss possible approaches to making the GUC system
> thread-safe. In particular, I want to talk about the global
> variables.
>
> A GUC parameter is defined via a struct config_generic record that
> contains some metadata and a
On Tue, Oct 7, 2025 at 2:57 PM Viktor Holmberg wrote:
> This patch is 85% the work of Andreas Karlsson and the reviewers (Dean
> Rasheed, Joel Jacobson, Kirill Reshke) in this thread:
> https://www.postgresql.org/message-id/flat/2b5db2e6-8ece-44d0-9890-f256fdca9f7e%40proxel.se,
> which unfortun
On Tue, Nov 4, 2025 at 5:02 AM Jonathan Gonzalez V.
wrote:
> * In Kubernetes, even with a network isolation, people use to prefer
> having TLS connections, just because it's the standard, but in internal
> communications (between namespaces and pods), these domains contain the
> format: ..svc..loc
On Tue, Nov 4, 2025 at 10:23 AM Jacob Champion
wrote:
> Thanks! I've added the tag; let's see how this goes.
Additionally, I've created a wiki category to hold the summaries:
https://wiki.postgresql.org/wiki/Category:OAuth_Working_Group
--Jacob
On 15.11.25 01:06, Thomas Munro wrote:
Our assertion quality is lower on Visual Studio. I assumed there was
nothing stopping us from writing a pg_expr_has_type_p() macro using
pure standard C and C++ these days, and the attached patch seemed to
work on GCC, Clang and Visual Studio 2022 (via CI,
[1] uses bottom-up approach to check if scan/join path already happens to
produce distinct rows, in order to avoid the DISTINCT step of planning. It
does so by conveying the uniqueness information ("unique keys") from
individual table/index scans to the upper planner. The concept is similar to
"pa
On Wed, Nov 19, 2025 at 9:07 AM Álvaro Herrera wrote:
> You could feed the message catalog a translated string that differs from
> the original in some simple way, say, by adding a constant prefix
> "[translated]" or something like that.
`xgettext -m` can do that. (But I wish I'd known about msge
On 2025-11-19 12:27:30 -0500, Robert Haas wrote:
> It's possible, but fundamentally I think it's about replacing
> XLogRecPtrIsInvalid with XLogRecPtrIsValid, and what I'm saying is I
> wouldn't have chosen to do that. I agree that it would have been
> better to do it that way originally, but I dis
On Tue, Nov 18, 2025 at 5:27 PM Chao Li wrote:
> Thanks for addressing the comments. V5 looks good to me.
Thanks both for the patch and review!
-where all_publication_object is one
of:
+where table_spec is:
+
+[ ONLY ] table_name [ * ] [ ( column_name [, ... ] ) ] [ WHERE (
expressio
Hi,
On Wed, Nov 19, 2025 at 12:27:30PM -0500, Robert Haas wrote:
> On Wed, Nov 19, 2025 at 11:49 AM Álvaro Herrera wrote:
> > > I'm rather late to the party here, but for what it's worth, I don't
> > > really think this was a good idea. Anyone who wants to write
> > > out-of-core code that works
On Tue, Nov 18, 2025 at 9:18 PM Michael Paquier wrote:
> This is following the same pattern as what has been introduced in
> 7dedfd22b798 for the other unsigned types in int.h. Anyway, looking
> at that separately, the logic of 0001 seems right here.
Okay, good. Thanks for the review!
> > 2) I
On Tue, Nov 18, 2025 at 5:17 PM Chao Li wrote:
> I just reviewed the patch. Overall looks solid to me.
Thanks for the review!
> Putting “…” inside a function body looks quite uncommon. I searched over the
> source tree and couldn't find other occurrence. As the comment has explained
> why omit
Hi Sawada-san,
Thank you very much for your detailed review and suggestions for the v2
patch.
Also, thank you for pointing out the top-posting issue. I'll follow the
mailing list style from now on.
---
>+ /* Report memory usage for dead_items tracking */
>+ vac_work_mem = AmAu
On Wed, Nov 19, 2025 at 11:49 AM Álvaro Herrera wrote:
> > I'm rather late to the party here, but for what it's worth, I don't
> > really think this was a good idea. Anyone who wants to write
> > out-of-core code that works in the back-branches must still write it
> > the old way, or it will poten
On Mon, Oct 20, 2025 at 8:15 AM torikoshia wrote:
> > S1: Set an injection point to wait in HandleLogQueryPlanInterrupt
> > [runs to completion].
> > S2: Take an advisory lock [runs to completion].
> > S1: Start a query that attempts to acquire the same advisory lock.
> > Use $node->wait_for_event
On Wed, 19 Nov 2025 at 16:51, Viktor Holmberg wrote:
>
> For the CASE default, elog(ERROR, "unrecognized LockClauseStrength %d” that
> was removed.
> Would this now trigger a compile time error/warning? And are you supposed to
> get 0 warnings when compiling?
That shouldn't trigger a warning, b
On 2025-Nov-19, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 19.11.25 04:15, Tom Lane wrote:
> >> I think we should do it
> >> honestly with a regression test. It doesn't need to be very
> >> complicated --- I think checking one message in one translation is
> >> sufficient, so long as it i
David Geier writes:
> On 19.11.2025 03:19, Tom Lane wrote:
>> I spent some effort on actually measuring timings of the v6 patch,
>> and concluded that this is all splitting hairs that we don't need
>> to split. The actual crossover between hash-loses and hash-wins
>> is more than what my theoreti
On Wed, Nov 19, 2025 at 11:02:08AM -0500, Robert Haas wrote:
> On Fri, Nov 14, 2025 at 12:14 PM Andres Freund wrote:
> > I'm rather baffled by the process here. You pushed a patch, without any
> > review, which also wasn't previously posted publicly, that made things
> > worse. Then, after you got
On Tue, Nov 18, 2025 at 11:26 PM David Geier wrote:
> On 22.10.2025 15:32, Andres Freund wrote:
> > On 2025-09-01 12:36:24 +0200, David Geier wrote:
> >>> Open questions I have:
> >>> - Could we rely on checking whether the TSC timesource is invariant
> (via
> >>> CPUID), instead of relying on Li
On 19 Nov 2025 at 15:08 +0100, Dean Rasheed , wrote:
> I made a quick pass over the code, and I'm attaching a few more
> suggested updates. This is mostly cosmetic stuff (e.g., fixing a few
> code comments that were overlooked), plus some minor refactoring to
> reduce code duplication.
Neat!
For th
On 2025-Nov-19, Robert Haas wrote:
> On Thu, Nov 6, 2025 at 2:48 PM Álvaro Herrera wrote:
> > Okay, thanks, I have applied that one to all stable branches, except
> > I didn't add the judgemental comment about XLogRecPtrIsInvalid().
>
> I'm rather late to the party here, but for what it's worth,
One more small issue: The docs for pg_resetwal contain recipes for how
to determine safe values to use:
-m mxid,mxid
--multixact-ids=mxid,mxid
Manually set the next and oldest multitransaction ID.
A safe value for the next multitransaction ID (first part) can be
determined by looking for the n
On Thu, Nov 6, 2025 at 2:48 PM Álvaro Herrera wrote:
> Okay, thanks, I have applied that one to all stable branches, except I
> didn't add the judgemental comment about XLogRecPtrIsInvalid().
I'm rather late to the party here, but for what it's worth, I don't
really think this was a good idea. An
On Tue, Nov 18, 2025 at 04:30:14PM -0500, Melanie Plageman wrote:
> I wish we could say "* number of unfrozen tuples". I know that's not
> true because we don't know how many tuples are on each page, but the
> formula feels a little overly detailed this way. Anyway, this is fine.
> I didn't apply a
On Fri, Nov 14, 2025 at 12:14 PM Andres Freund wrote:
> I'm rather baffled by the process here. You pushed a patch, without any
> review, which also wasn't previously posted publicly, that made things
> worse. Then, after you got pushback on that change, you posted another patch,
> that got mildly
On 19.11.2025 18:38, David Geier wrote:
On 19.11.2025 03:19, Tom Lane wrote:
I spent some effort on actually measuring timings of the v6 patch,
and concluded that this is all splitting hairs that we don't need
to split. The actual crossover between hash-loses and hash-wins
is more than what
Peter Eisentraut writes:
> On 14.11.25 22:11, Tom Lane wrote:
>> "leapyear" is bool, and I believe these casts-to-int were put in to
>> suppress compiler bleats about up-casting that to int. This probably
>> dates from when we equated bool to char, and maybe it's moot now,
>> but I'm not sure.
>
Peter Eisentraut writes:
> On 19.11.25 04:15, Tom Lane wrote:
>> I think we should do it
>> honestly with a regression test. It doesn't need to be very
>> complicated --- I think checking one message in one translation is
>> sufficient, so long as it includes a PRI?64 usage.
> We could generate
On 19.11.2025 03:19, Tom Lane wrote:
> I wrote:
>> Thinking a bit harder, we are comparing these costs:
>> [ theoretical arguments trimmed ]
>
> I spent some effort on actually measuring timings of the v6 patch,
> and concluded that this is all splitting hairs that we don't need
> to split. The a
Here's a small patch to replace the int64 parsing code in pgbench with a
call to strtoi64(). Makes it a little simpler.
Spotted this while grepping for all the different integer parsing
functions we have. We could probably consolidate them some more, we
still have quite a different integer-par
Hi Team,
i have one more question :
with every version of package installation , PG 17 version is getting by
default installed, is it a hard dependency or bug?
*[root@db1 ~]# dnf install -y postgresql16-server postgresql16-contrib
-y*Updating
Subscription Management repositories.
Unable to read
On Wed, Nov 19, 2025 at 11:36 PM Mircea Cadariu
wrote:
>
> Hi,
>
>
> Update: I added another test to the attached test-only patch. This new
> test uses pg_terminate_backend to trigger reconnection.
>
> Assuming the tests are fully correct (your input appreciated on this) we
> can use them to valid
Hi,
Update: I added another test to the attached test-only patch. This new
test uses pg_terminate_backend to trigger reconnection.
Assuming the tests are fully correct (your input appreciated on this) we
can use them to validate the solution.
Kind regards,
Mircea Cadariu
From dfb6e7d49c
> On 19 Nov 2025, at 15:17, Fujii Masao wrote:
> So I will commit v3 patch.
+1
--
Daniel Gustafsson
On Wed, Nov 19, 2025 at 10:57 PM Peter Eisentraut wrote:
> My point was a different one. It is generally preferable to separate
> translatable and untranslated things. So, as an example from elsewhere,
> instead of
>
> errhint("Use ALTER DOMAIN instead.");
>
> it would be better to use
>
> errhi
Hi Thomas,
> It passes with VS 2022 on CI. I had to skip some assertions about
> macros promising lock-free implementation, that it doesn't define in C
> mode yet. They are definitely lock-free though[1], and the macros are
> defined for C++, and the same under the covers... Perhaps
> feature/c
On 19.11.25 14:47, Fujii Masao wrote:
On Wed, Nov 19, 2025 at 10:04 PM Daniel Gustafsson wrote:
On 19 Nov 2025, at 14:01, Fujii Masao wrote:
You changed the HINT message to use format arguments,
but I still think it's better to embed the values directly (e.g.,
Valid encodings are "base64"
On Wed, Nov 19, 2025 at 1:00 AM Bruce Momjian wrote:
> Yeah, you are probably right. I didn't see that. You should apply it
> since it is your patch, thanks.
Okay, so barring any objection, I will commit the attached patch.
Regards,
--
Fujii Masao
v1-0001-doc-Update-pg_upgrade-documentatio
On Wed, Nov 19, 2025 at 09:28:09AM +, Bertrand Drouvot wrote:
> Option 1:
>
> We could simply create the pg_buffercache_os_pages view on top of the
> pg_buffercache_numa one. The cons I can think of is that, when numa is
> available,
> then pg_buffercache_os_pages would pay the extra cost tha
On Wed, Nov 19, 2025 at 10:04 PM Daniel Gustafsson wrote:
>
> > On 19 Nov 2025, at 14:01, Fujii Masao wrote:
>
> > You changed the HINT message to use format arguments,
> > but I still think it's better to embed the values directly (e.g.,
> > Valid encodings are "base64", "base64url", "escape", a
Hi,
On Wed, Nov 19, 2025 at 11:44 AM Xuneng Zhou wrote:
>
> Hi Michael,
>
> On Sat, Nov 8, 2025 at 7:03 AM Michael Paquier wrote:
> >
> > On Fri, Nov 07, 2025 at 09:48:23PM +0800, Xuneng Zhou wrote:
> > > Now that the LSN-waiting infrastructure (3b4e53a) and WAL replay
> > > wake-up calls (447aa
> On 19 Nov 2025, at 14:01, Fujii Masao wrote:
> You changed the HINT message to use format arguments,
> but I still think it's better to embed the values directly (e.g.,
> Valid encodings are "base64", "base64url", "escape", and "hex".)
> for consistency with similar HINT messages. If this messa
On Wed, Nov 19, 2025 at 8:08 PM Sugamoto Shinya wrote:
>
> Thanks everyone for reviewing my proposal. Please let me know if you have
> something to discuss here.
+errhint("Valid encodings are \"%s\",
\"%s\", \"%s\", and \"%s\".",
+
On 18.11.2025 20:37, Tomas Vondra wrote:
>
>
> On 11/18/25 19:35, David Geier wrote:
>>
>> On 18.11.2025 18:31, Tomas Vondra wrote:
>>> On 11/18/25 17:51, Tom Lane wrote:
David Geier writes:
> On 18.11.2025 16:40, Tomas Vondra wrote:
>> It'd need code in the parallel-aware scans, i.
The use of the *synced *flag could perhaps be a first step towards
distinguishing between a synchronization slot on a standby and a failover
slot created on a standby.
On the primary, *synced* should always be false.
On a secondary, actually *synced* remains true even if the parameter
sync_replicat
Chao Li writes:
> On Wed, Nov 19, 2025 at 4:33 PM Peter Eisentraut
> wrote:
>
>> I find the data structures that you have constructed here barely
>> understandable:
>>
>> my %required_by_type = (
>> int => [qw(min max)],
>> real => [qw(min max)],
>> enum => [qw(o
Re: Álvaro Herrera
> Christoph, can you please confirm that this is approximately what you
> had in mind? Other names are of course possible.
Sorry for the late reply, the mail got lost in my inbox.
Yes that's what I had in mind.
> I didn't immediately love this idea, but I'm not totally oppose
On Tue, Nov 18, 2025 at 7:32 PM Andrey Silitskiy
wrote:
>
> Dear pgsql-hackers,
>
> I am also interested in solving this problem, so I suggest a patch which
> is based on Hayato's work shared earlier.
+1
Thanks for the patch!
+{ name => 'logical_wal_sender_shutdown_mode', type => 'enum', context
On Wednesday, November 19, 2025 4:24 PM Hou, Zhijie
wrote:
>
> On Monday, November 17, 2025 6:50 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> >
> > Attach v2 patch that improves the fix based on above analysis.
> >
> > (I am still testing some other scenarios related to slotsync to ensure the
> > curr
On 13.11.25 12:35, Thomas Munro wrote:
It passes with VS 2022 on CI. I had to skip some assertions about
macros promising lock-free implementation, that it doesn't define in C
mode yet. They are definitely lock-free though[1], and the macros are
defined for C++, and the same under the covers...
Hi Melanie,
Thank you for the detailed clarifications which helped me understand
the constraints much more clearly. You are absolutely right regarding
the key points you specified. My initial concern came from trying to
avoid cases where strategy pin limits were unexpectedly small (0 or
negative)
On Thu, Nov 13, 2025 at 10:47 AM wenhui qiu wrote:
>
> Hi
> > Since no more suggestions have been provided. And this is a very minor
> > change. Although there are currently no other documents linked to these
> > tags. This patch makes this document more complete and in line with
> > conventions o
On Wed, Nov 19, 2025 at 3:46 PM Dilip Kumar wrote:
>
> On Tue, Nov 18, 2025 at 4:47 PM shveta malik wrote:
> >
> > Thanks for the patch. Some feedback about the clt:
> >
> > 1)
> > local_origin is always NULL in my tests for all conflict types I tried.
>
> You need to set the replication origin
Thanks everyone for reviewing my proposal. Please let me know if you have
something to discuss here.
2025年11月19日(水) 0:31 Nathan Bossart :
> On Wed, Nov 19, 2025 at 12:20:34AM +0900, Sugamoto Shinya wrote:
> > On Tue, Nov 18, 2025 at 1:07 PM Fujii Masao
> wrote:
> >> Is there a guideline on when
Thanks Álvaro
Will work on it and send the updated patch.
On Wed, Nov 19, 2025 at 4:17 PM Álvaro Herrera wrote:
> Hello,
>
> One thing I realized a few days ago is that since commit bd09f024a1bb we
> have type regdatabase, so instead of having two functions (one taking
> name and one taking Oid)
On Wed, Nov 19, 2025 at 3:48 PM Japin Li wrote:
>
> Hi Akshay,
>
> Thanks for updating the patch.
>
> On Tue, 18 Nov 2025 at 13:33, Akshay Joshi
> wrote:
> > Hi Chao
> >
> > Thanks for reviewing my patch.
> >
> > On Tue, Nov 18, 2025 at 5:59 AM Chao Li wrote:
> >
> > Hi Akshay,
> >
> > I just
Hello,
One thing I realized a few days ago is that since commit bd09f024a1bb we
have type regdatabase, so instead of having two functions (one taking
name and one taking Oid), we should have just one, taking regdatabase,
just like the functions for producing DDL for other object types that
have co
On 2025-Nov-18, Euler Taveira wrote:
> On Thu, Nov 6, 2025, at 1:01 PM, Alvaro Herrera wrote:
> See miscadmin.h.
>
> /*
> * MyBackendType indicates what kind of a backend this is.
> *
> * If you add entries, please also update the child_process_kinds array in
> * launch_backend.c.
> */
> ty
On Wed, Nov 19, 2025 at 3:22 PM Fujii Masao wrote:
> Attached is a patch implementing this idea.
> I've also added it to the next CommitFest.
I've fixed the compiler warning issue.
Attached is an updated version of the patch.
Regards,
--
Fujii Masao
v2-0001-Honor-GUC-settings-specified-in-CR
On Wed, Nov 19, 2025 at 5:36 PM Peter Eisentraut
wrote:
>
>
> In a couple of cases, you are changing the type of the loop variable
> from Size to int. I would not expect such a change in a patch of this
> nature. If you have a reason to change it, please explain it (but I
> doubt the change is
Hi Akshay,
Thanks for updating the patch.
On Tue, 18 Nov 2025 at 13:33, Akshay Joshi
wrote:
> Hi Chao
>
> Thanks for reviewing my patch.
>
> On Tue, Nov 18, 2025 at 5:59 AM Chao Li wrote:
>
> Hi Akshay,
>
> I just reviewed v3 and got some comments:
>
> > On Nov 17, 2025, at 22:34, Akshay
On Tue, Nov 18, 2025 at 4:47 PM shveta malik wrote:
>
> Thanks for the patch. Some feedback about the clt:
>
> 1)
> local_origin is always NULL in my tests for all conflict types I tried.
You need to set the replication origin as shown below
On subscriber side:
---
SELECT
On Mon, 17 Nov 2025 at 11:35, Peter Smith wrote:
>
> On Tue, Nov 11, 2025 at 9:22 PM Shlok Kyal wrote:
> >
> > On Fri, 7 Nov 2025 at 09:34, Peter Smith wrote:
> > >
> > > Hi Shlok.
> > >
> > > This is a general comment about the content of these patches.
> > >
> > > IIUC, the v25* patches curren
On 12.11.25 09:00, Chao Li wrote:
While working on the other patch [1] that touched tbm_add_tuples() under
src/backend/nodes, I moved a loop variable into for statement by the way
as I knew Peter Eisentraut had done some efforts about that, see [2].
However, Peter removed that change from the
On Tue, 18 Nov 2025 at 04:07, Melanie Plageman
wrote:
>
> Attached v20 has general cleanup, changes to the table/index AM
> callbacks detailed below, and it moves the
> heap_page_prune_and_freeze() refactoring commit down the stack to
> 0004.
>
> 0001 - 0003 are fairly trivial cleanup patches. I t
On 14.11.25 22:11, Tom Lane wrote:
Peter Eisentraut writes:
On 12.11.25 19:02, Tom Lane wrote:
Hm, I've had "re-sync TZ code with upstream" on my TODO list for
several years now. I believe there's been quite a bit of churn
upstream since tzcode2020d, some of it oriented towards this same
issu
Hi,
On Tue, Nov 18, 2025 at 02:39:36PM +0900, Michael Paquier wrote:
> On Fri, Aug 22, 2025 at 08:48:57AM +, Bertrand Drouvot wrote:
> > Yeah, I think so. Thanks for the ping, done in attached.
>
> The patch has been marked as ready for committer, and I see the value
> in providing a view whe
On Wed, Nov 19, 2025 at 1:52 AM Masahiko Sawada wrote:
>
> On Mon, Nov 17, 2025 at 10:49 PM Amit Kapila wrote:
> >
> > On Tue, Nov 18, 2025 at 1:02 AM Masahiko Sawada
> > wrote:
> > >
> > > On Sun, Nov 16, 2025 at 9:51 PM Amit Kapila
> > > wrote:
> > >
> > > >
> > > > In v26-0002-FIXUP-remove
On 19.11.25 03:13, Thomas Munro wrote:
Interesting report though. Commit 962da900 assumed that our in-tree
printf implementation still needed to understand that %I64 stuff in
case it came to us from system headers, but it looks like it
disappeared with MSVCRT:
1. I checked with CI (VS 2019). p
On Wed, Nov 19, 2025 at 4:33 PM Peter Eisentraut
wrote:
> I find the data structures that you have constructed here barely
> understandable:
>
> my %required_by_type = (
> int => [qw(min max)],
> real => [qw(min max)],
> enum => [qw(options)],
> );
>
> f
On 19.11.25 04:15, Tom Lane wrote:
Thomas Munro writes:
Perhaps meson/configure should do a po -> mo -> gettext() check with a
canned test message? That'd also make sure your msgfmt and libintl
are compatible, something I worried about when I wrote about musl
recently.
No, I don't think that
I find the data structures that you have constructed here barely
understandable:
my %required_by_type = (
int => [qw(min max)],
real => [qw(min max)],
enum => [qw(options)],
);
for my $f (@required_common, @{ $required_by_type{$entry->{type} //
''} // [] })
On Monday, November 17, 2025 6:50 PM Zhijie Hou (Fujitsu)
wrote:
>
>
> Attach v2 patch that improves the fix based on above analysis.
>
> (I am still testing some other scenarios related to slotsync to ensure the
> current fix is complete)
I have been testing whether taking exclusive Replicat
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:
> > > []
> > Kindly have a look at the attached version. Thank you !
> >
On 18.11.25 23:39, David Rowley wrote:
On Tue, 18 Nov 2025 at 21:50, Peter Eisentraut wrote:
where get_config_val_*() would be a thin wrapper around hash_search()
(a bit like the existing GetConfigOption() and find_option(), but
without all the error checking).
Would that be too expensive?
W
92 matches
Mail list logo
