On Tue, 9 Dec 2025, 10:08 jian he, wrote:
> hi.
>
> While working on CAST DEFAULT, I found out citext_1.out, citext.out
> comments are
> confusing.
>
> contrib/citext/expected/citext_1.out:
> SELECT 'a'::citext >= 'B'::text AS t; -- text wins.
> t
> ---
> f
> (1 row)
>
>
> contrib/citext/expec
Hi,
On Mon, Dec 08, 2025 at 11:53:02AM +0100, Jelte Fennema-Nio wrote:
> On Sat Dec 6, 2025 at 1:56 AM CET, Thomas Munro wrote:
> > On Sat, Dec 6, 2025 at 3:32 AM Jelte Fennema-Nio wrote:
> > > On Fri, 5 Dec 2025 at 02:30, Thomas Munro wrote:
> > > create a hashmap it's still possible to call th
On 04.12.25 14:51, Bertrand Drouvot wrote:
On Thu, Dec 04, 2025 at 01:19:07PM +0100, Peter Eisentraut wrote:
Attached are some patches to remove unnecessary casts in printf format
arguments. Many of these are apparently left over from before use of
%zu/%zd and PRIu64/PRId64 were possible. Addi
On Tue, Dec 9, 2025 at 10:12 AM Amit Kapila wrote:
>
> On Mon, Dec 8, 2025 at 5:15 PM Dilip Kumar wrote:
> >
> > On Mon, Dec 8, 2025 at 3:21 PM Amit Kapila wrote:
> > >
> > > On Mon, Dec 8, 2025 at 3:01 PM Dilip Kumar wrote:
> > > >
> > > > On Mon, Dec 8, 2025 at 2:38 PM Amit Kapila
> > > > w
On Monday, December 8, 2025, tushar wrote:
>
>
> So this query is a failed query and now if i give 'postgres' instead of
> 'abc123', Am I not supposed to get the same error , instead of
> pg_dump overwriting the postgres executable.
>
The code chooses to initialize the archive first, then open th
> On Dec 9, 2025, at 14:12, Amit Kapila wrote:
>
> On Tue, Dec 9, 2025 at 11:23 AM Chao Li wrote:
>>
>>
>> Yeah, I just searched and see similar messages:
>>
>> ```
>> logical replication parallel apply worker for subscription \"%s\" will stop
>> because the subscription owner's superuser
On Tue, Dec 9, 2025 at 11:23 AM Chao Li wrote:
>
>
> Yeah, I just searched and see similar messages:
>
> ```
> logical replication parallel apply worker for subscription \"%s\" will stop
> because the subscription owner's superuser privileges have been revoked
>
> logical replication worker for s
On Tuesday, December 9, 2025 1:34 PM Amit Kapila
wrote:
>
> On Mon, Dec 8, 2025 at 1:06 PM Chao Li wrote:
> >
> > I have nit comment:
> >
> > ```
> > - if (ShutdownRequestPending)
> > + if (SlotSyncCtx->stopSignaled)
> > {
> > ereport(LOG,
> > -
> On Dec 9, 2025, at 13:34, Amit Kapila wrote:
>
> On Mon, Dec 8, 2025 at 1:06 PM Chao Li wrote:
>>
>> I have nit comment:
>>
>> ```
>> - if (ShutdownRequestPending)
>> + if (SlotSyncCtx->stopSignaled)
>>{
>>ereport(LOG,
>> -
On Tue, Dec 9, 2025 at 11:12 AM Tom Lane wrote:
>
> There is no point in trying to prevent pg_dump from overwriting a
> postgres executable when there are thousands of other ways to do
> that, if you're foolish enough to not be more careful with file
> permissions.
>
> right. The responsibility f
tushar writes:
> So this query is a failed query and now if i give 'postgres' instead of
> 'abc123', Am I not supposed to get the same error , instead of
> pg_dump overwriting the postgres executable.
No. You are supposed to be someone who knows better --- and if you
don't, you should not be run
> On Dec 9, 2025, at 13:23, Chao Li wrote:
>
>
>
>> On Dec 9, 2025, at 12:45, Michael Paquier wrote:
>>
>> It seems to me that you are missing nothing here, and that Chao has
>> missed the fact that the end of pgstat_read_statsfile() does a "goto
>> done", meaning that we would take a roun
On Tue, Dec 09, 2025 at 12:08:58AM -0500, Kirk Wolak wrote:
> Our understanding is that many people run into this exact issue. The
> cache needs small frequent updates.
> (After reading the code that handles MVs, we just created our own TABLE,
> and maintain it with a scheduler to rebuild HOURLY
On Mon, Dec 8, 2025 at 1:06 PM Chao Li wrote:
>
> I have nit comment:
>
> ```
> - if (ShutdownRequestPending)
> + if (SlotSyncCtx->stopSignaled)
> {
> ereport(LOG,
> - errmsg("replication slot synchronization
> worker is shutting d
jian he writes:
> Some of the regexp* function error messages seem not very helpful, I think.
> like:
> ereport(ERROR,
> errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("invalid value for parameter \"%s\": %d",
> "start", start));
> so I added a
On Mon, Dec 8, 2025 at 11:50 PM Tom Lane wrote:
> tushar writes:
> > I found a scenario where, after firing the wrong way of using the
> pg_dump
> > command, not only server fail to start,
> > But later, I am not able to perform initdb/pg_ctl as well
>
> > The result is :
> > edb@1a1c15437e7c
> On Dec 9, 2025, at 12:45, Michael Paquier wrote:
>
> It seems to me that you are missing nothing here, and that Chao has
> missed the fact that the end of pgstat_read_statsfile() does a "goto
> done", meaning that we would take a round of
No, I didn’t miss that part. But in the “done” claus
hi.
Some of the regexp* function error messages seem not very helpful, I think.
like:
ereport(ERROR,
errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("invalid value for parameter \"%s\": %d",
"start", start));
so I added a errhint, errhint would be
On Mon, Dec 8, 2025 at 3:58 PM Adam Brusselback
wrote:
> Attached is a patch implementing support for a WHERE clause in REFRESH
> MATERIALIZED VIEW.
>
> The syntax allows for targeted refreshes:
> REFRESH MATERIALIZED VIEW mv WHERE invoice_id = ANY('{1,2,3}');
> REFRESH MATERIALIZED VIEW
hi.
While working on CAST DEFAULT, I found out citext_1.out, citext.out comments are
confusing.
contrib/citext/expected/citext_1.out:
SELECT 'a'::citext >= 'B'::text AS t; -- text wins.
t
---
f
(1 row)
contrib/citext/expected/citext.out:
SELECT 'a'::citext >= 'B'::text AS t; -- text wins.
On Mon, Dec 08, 2025 at 09:57:15PM -0600, Sami Imseih wrote:
> The way v5 is dealing with a deserialize failure is that when
> it goes to error, the pgstat_reset_after_failure() will reset the
> stats for all kinds, since pgstat_drop_all_entries() is called
> during that call. So there is nothing f
On Mon, Dec 8, 2025 at 5:15 PM Dilip Kumar wrote:
>
> On Mon, Dec 8, 2025 at 3:21 PM Amit Kapila wrote:
> >
> > On Mon, Dec 8, 2025 at 3:01 PM Dilip Kumar wrote:
> > >
> > > On Mon, Dec 8, 2025 at 2:38 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, Dec 8, 2025 at 10:25 AM Dilip Kumar
>
On Tue, Dec 9, 2025 at 12:22 AM Masahiko Sawada wrote:
>
> On Mon, Dec 8, 2025 at 3:30 AM Amit Kapila wrote:
> >
> > On Mon, Dec 8, 2025 at 1:06 PM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Dec 5, 2025 at 4:56 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > >
> > > > > Hmm, ISTM that the
Hi,
On 2025-12-04 12:41:26 -0600, Nathan Bossart wrote:
> On Thu, Dec 04, 2025 at 01:15:55PM -0500, Tom Lane wrote:
> > LGTM otherwise.
>
> +1
Thanks for the reviews Tom and Nathan. Pushed with minor further tweaks
(s/due to/via/, s/concurent/concurrent/).
Greetings,
Andres Freund
> Using PANIC is an inherited historical artifact that has been
> introduced around 4d14fe0048cf with the introduction of WAL. There
> was nothing like archiving or even base backup back then. Switching
> the existing surrounding one to also use a FATAL is something that
> seems worth considering
> + if
> (kind_info->from_serialized_extra_stats)
> + {
> + if
> (!kind_info->from_serialized_extra_stats(&key, header, fpin))
> +
On Fri, Nov 21, 2025 at 4:28 AM Melanie Plageman
wrote:
> I'm not totally opposed to this. My rationale for making it an error
> is that the developer could have test cases where all the buffers are
> consumed but the code is written such that that won't always happen.
> Then if a real production
On Mon, Dec 1, 2025 at 1:41 PM Corey Huinker wrote:
>>
>> >> I'm fine with it. I can see having 'f' and 's' both mean cast functions,
>> >> but 's' means safe, but the extra boolean works too and we'll be fine
>> >> with either method.
>> >
>> >
>> > I can work on this part if you don't have tim
> On Dec 9, 2025, at 03:09, Sami Imseih wrote:
>
>> Yes, thanks. Structurally, this is better and more flexible than what
>> we had originally, and I have noticed that you have copied the
>> original files while adding more comments and renaming a bit things:
>> the structure of the functions
On Tuesday, December 9, 2025 12:40 AM Vitaly Davydov
wrote:
>
> On Monday, December 08, 2025 13:24 MSK, "Zhijie Hou (Fujitsu)"
> wrote:
>
> > On Monday, December 8, 2025 5:47 PM Amit Kapila
> wrote:
> > > > > Sawada-san/Vitaly, do you have any opinion on patch or the
> > > > > direction to fi
Sigh ... I should know better than to assume meson code will work
without testing it. One-line fix in v5-0002.
regards, tom lane
From 672e889c76194985c9c325b3500c26e0583f Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Mon, 8 Dec 2025 17:40:00 -0500
Subject: [PATCH v5
On Tue, 9 Dec 2025 at 08:41, David Geier wrote:
> Attached patch fixes a repetition in the user-facing hash index
> documentation and the README.
Thanks. I can take care of that. I'll backpatch to v15 due to the sgml
docs. The README issue exists in v14, but likely isn't doing enough
harm to warr
Hello,
On Fri, Dec 5, 2025 at 11:57 AM Robert Haas wrote:
> 014f9a831a320666bf2195949f41710f970c54ad removes the need for what was
> previously 0004, so here is a new patch series with that dropped, to
> avoid confusing cfbot or human reviewers.
I really like this idea! Telling the planner, "if
Bryan Green writes:
> On 12/8/2025 1:23 PM, Tom Lane wrote:
>> I don't know whether the attached will pass on Windows: we might
>> not be able to assume that "es_ES" is the right LC_MESSAGES
>> setting to use. But it works for me on Linux.
> gettext() will be fine with that if you are using < 0.
On Tue, 9 Dec 2025 at 04:37, Sergey Soloviev
wrote:
> I would like to introduce new GROUP BY strategy, called Index Aggregate.
> In a nutshell, we build B+tree index where GROUP BY attributes are index
> keys and if memory limit reached we will build index for each batch and
> spill it to the dis
> On Dec 9, 2025, at 03:24, Nathan Bossart wrote:
>
> On Mon, Dec 08, 2025 at 12:27:26PM -0600, Nathan Bossart wrote:
>> On Mon, Dec 08, 2025 at 07:23:16PM +0100, Álvaro Herrera wrote:
>>> I haven't read this thread, but chanced to come across this and wanted
>>> to note recent commit c05dee19
On Tue, Dec 09, 2025 at 07:33:17AM +0900, Noboru Saito wrote:
> I'm a member of the PostgreSQL Japanese documentation translation team.
> While working on the translation, I found some inconsistent title
> attribute tags in the documentation.
>
> I am submitting a patch to fix these tag inconsiste
Hi PostgreSQL Hackers,
I'm a member of the PostgreSQL Japanese documentation translation team.
While working on the translation, I found some inconsistent title
attribute tags in the documentation.
I am submitting a patch to fix these tag inconsistencies in pgbuffercache.sgml.
This has been an is
On Sun, Dec 07, 2025 at 11:32:28PM +0900, Sugamoto Shinya wrote:
> Attached is the new patch. One possible discussion point is that I choose
> FATAL over ERROR at src/backend/commands/copy.c#L816, since reaching that
> point would indicate an implementation problem. Please let me know if
> there is
On Mon, Dec 8, 2025 at 4:43 PM Jelte Fennema-Nio wrote:
> On Sun, 7 Dec 2025 at 15:38, Dave Cramer wrote:
> > My main driver here is to allow the creation of Holdable portals at the
> protocol level for drivers.
>
> Overall seems like a sensible feature to want. A somewhat random
> collection of
On Mon, Dec 08, 2025 at 08:45:07PM +0100, Álvaro Herrera wrote:
> This looks reasonable to me in a quick read.
Thanks. Unless there is more feedback, I plan to commit these tomorrow.
--
nathan
On Sun, 7 Dec 2025 at 15:38, Dave Cramer wrote:
> My main driver here is to allow the creation of Holdable portals at the
> protocol level for drivers.
Overall seems like a sensible feature to want. A somewhat random
collection of thoughts:
1. We still have fairly limited experience with protoc
On Thu, Dec 4, 2025 at 8:30 PM Shinya Kato wrote:
>
> Thank you for the review!
>
> On Thu, Dec 4, 2025 at 9:15 AM Masahiko Sawada wrote:
> > I've attached a small change to simplify the 0001 patch. Please review it.
>
> LGTM, and I've updated in v9 patches.
>
> > Here are a few comments:
> >
> >
On Sun, Dec 7, 2025 at 6:32 AM Sugamoto Shinya wrote:
>
>
>
> On Thu, Dec 4, 2025 at 4:35 PM Kirill Reshke wrote:
>>
>> 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 fu
On Tue, Nov 25, 2025 at 11:54 PM Michael Paquier wrote:
> > Tom, you are registered as a reviewer of the patch. The point of
> > contention of the patch, where I see there is no consensus yet, is if
> > my approach of using a redirection for the external TOAST pointers
> > with a new layer to fac
Attached is a patch implementing support for a WHERE clause in REFRESH
MATERIALIZED VIEW.
The syntax allows for targeted refreshes:
REFRESH MATERIALIZED VIEW mv WHERE invoice_id = ANY('{1,2,3}');
REFRESH MATERIALIZED VIEW CONCURRENTLY mv WHERE customer_id = 42;
REFRESH MATERIALIZED VIE
On Fri, Dec 5, 2025, at 2:57 PM, Robert Haas wrote:
> 014f9a831a320666bf2195949f41710f970c54ad removes the need for what was
> previously 0004, so here is a new patch series with that dropped, to
> avoid confusing cfbot or human reviewers.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
Hi,
I've spent the last couple days considering what to do about this patch
series in this thread. The approach assumes partitioning shared memory
in a NUMA-aware way has enough benefits to justify the extra complexity.
I'm getting somewhat skeptical about that being a good trade off.
We've been
On 2025-Dec-08, Nathan Bossart wrote:
> On Mon, Dec 08, 2025 at 12:27:26PM -0600, Nathan Bossart wrote:
> > On Mon, Dec 08, 2025 at 07:23:16PM +0100, Álvaro Herrera wrote:
> >> I haven't read this thread, but chanced to come across this and wanted
> >> to note recent commit c05dee191125. I'm not
Hi,
I did not look into this patch in detail yet, but I am +1 for being
able to create cursors at the protocol level.
I think this should be allowed for regular cursors as well. One
big use-case I see is allowing postgres_fdw to create and fetch
from cursors at the protocol level rather than SQL
On 12/8/2025 1:23 PM, Tom Lane wrote:
> This was discussed a few weeks ago in [1], but I'm starting a
> new thread so as not to confuse things with the latest patches in
> that thread. The issue is that it seems like it'd be a good idea to
> have specific regression testing of whether translation
Hi hackers!
Attached patch fixes a repetition in the user-facing hash index
documentation and the README.
--
David GeierFrom 6420ef7f24f150c88110343634758ae8fb3a779d Mon Sep 17 00:00:00 2001
From: David Geier
Date: Mon, 8 Dec 2025 20:37:02 +0100
Subject: [PATCH] Fix hash index documentation
---
Hi Fujii,
I did your patch review. It successfully applies to all targeted branches:
REL_14_STABLE (48969555447), REL_15_STABLE (b9a02b9780b), REL_16_STABLE
(4d689a17693), REL_17_STABLE (cad40cec24f), REL_18_STABLE (5278222853c) and
master (d0d0ba6cf66). All tests successfully pass on MacOS 15.7 f
On Mon, Dec 08, 2025 at 12:27:26PM -0600, Nathan Bossart wrote:
> On Mon, Dec 08, 2025 at 07:23:16PM +0100, Álvaro Herrera wrote:
>> I haven't read this thread, but chanced to come across this and wanted
>> to note recent commit c05dee191125. I'm not opposed to changing what
>> went in there, but
This was discussed a few weeks ago in [1], but I'm starting a
new thread so as not to confuse things with the latest patches in
that thread. The issue is that it seems like it'd be a good idea to
have specific regression testing of whether translation of the
PRI* macros works properly, since that
> Thanks for the review of the patch. Please find the attachment for the
> updated version.
Thanks! v2 LGTM
--
Sami Imseih
Amazon Web Services (AWS)
> Yes, thanks. Structurally, this is better and more flexible than what
> we had originally, and I have noticed that you have copied the
> original files while adding more comments and renaming a bit things:
> the structure of the functions was exactly the same. Anyway, I have
> worked on that fo
On Mon, Dec 1, 2025 at 3:31 PM Robert Haas wrote:
> So I'm wondering if we ought to step back and rethink a bit.
> subplanNames ensures that we assign a different name to every
> PlannerInfo, but it doesn't give you any help finding the PlannerInfo
> given the name, or enumerating all of the Plann
On Mon, Dec 8, 2025 at 3:30 AM Amit Kapila wrote:
>
> On Mon, Dec 8, 2025 at 1:06 PM Masahiko Sawada wrote:
> >
> > On Fri, Dec 5, 2025 at 4:56 PM Masahiko Sawada
> > wrote:
> > >
> > > >
> > > > Hmm, ISTM that the root cause is that we don't synchronously update
> > > > the XLogLogicalInfo cac
On Mon, Dec 8, 2025 at 4:13 AM Victor Yegorov wrote:
> I've compiled and run test (check and installcheck) with all 3 patches, did a
> small standard pgbench run:
> pgbench -s 100 -i
> pgbench -P 60 -T 300
>
> Results:
> master: 569 TPS
> patched: 590 TPS +3.7%
Pushed both patches just now.
Tha
On Mon, 8 Dec 2025 at 22:39, tushar wrote:
>
>
>
> On Mon, Dec 8, 2025 at 12:14 PM Mahendra Singh Thalor
> wrote:
>>
>>
>> I tried to fix these issues in the attached patch.
>>
>> Here, I am attaching an updated patch for the review and testing.
>
>
> Thanks Mahendra, I am not able to apply the
On 2025-Dec-08, Nathan Bossart wrote:
> On Mon, Dec 08, 2025 at 04:47:17PM +0100, Álvaro Herrera wrote:
> > Any objections to these changes?
>
> Nope, LGTM
Thanks, pushed.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"La virtud es el justo medio entre dos de
On Mon, Dec 08, 2025 at 07:23:16PM +0100, Álvaro Herrera wrote:
> I haven't read this thread, but chanced to come across this and wanted
> to note recent commit c05dee191125. I'm not opposed to changing what
> went in there, but let's make them all the same.
Ah, that must've been where I stole fr
On Mon, Dec 08, 2025 at 01:22:48PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> On Mon, Dec 08, 2025 at 11:23:53PM +0530, tushar wrote:
>>> Is there any way we can generate some error messages?
>
>> Perhaps it'd be worth making pg_dump a little more cautious about
>> overwriting existing fi
On Mon, Dec 08, 2025 at 01:20:13PM -0500, Tom Lane wrote:
> Don't do that. Generally speaking, you don't want installed files to
> be writable at all by ordinary user accounts ... but if they are,
> for heaven's sake don't cd into those directories before doing work.
> You're just setting yourself
On 2025-Dec-08, Nathan Bossart wrote:
> On Sat, Dec 06, 2025 at 07:48:22AM +0800, Chao Li wrote:
> > ```
> > + if (vacopts.dry_run)
> > + pg_log_info("Executing in dry-run mode.”);
> > ```
> >
> > Feels like “Running” is better than “Executing”.
>
> Done.
I haven't read this thread
Nathan Bossart writes:
> On Mon, Dec 08, 2025 at 11:23:53PM +0530, tushar wrote:
>> Is there any way we can generate some error messages?
> Perhaps it'd be worth making pg_dump a little more cautious about
> overwriting existing files (or at least have the option to avoid that).
I think we'd get
tushar writes:
> I found a scenario where, after firing the wrong way of using the pg_dump
> command, not only server fail to start,
> But later, I am not able to perform initdb/pg_ctl as well
> The result is :
> edb@1a1c15437e7c bin]$ ./pg_dump -Ft -s -c -v -f postgres schema_clean.tar1
> q
On Mon, Dec 08, 2025 at 11:23:53PM +0530, tushar wrote:
> I found a scenario where, after firing the wrong way of using the pg_dump
> command, not only server fail to start,
> But later, I am not able to perform initdb/pg_ctl as well
>
> Please refer to this testcase:
> "
> PG v19 devel, Cluste
On Sat, Dec 06, 2025 at 07:48:22AM +0800, Chao Li wrote:
> I just reviewed v5, and overall looks very good patch quality. Just a few
> nit comments on 0001 and 0003.
I've attached an updated patch set. After giving the "dry-run" messages
another look, I think we should just print a note at the ve
On 08/12/2025 11:13, Victor Yegorov wrote:
Even without the performance increase, I think this a valuable code
reorganization, worth committing.
+1
- Heikki
Hi,
I found a scenario where, after firing the wrong way of using the pg_dump
command, not only server fail to start,
But later, I am not able to perform initdb/pg_ctl as well
Please refer to this testcase:
"
PG v19 devel, Cluster running on default port=5432
Run pg_dump (./pg_dump -Ft -s -c
On Mon, Dec 8, 2025 at 12:14 PM Mahendra Singh Thalor
wrote:
>
> I tried to fix these issues in the attached patch.
>
> Here, I am attaching an updated patch for the review and testing.
>
Thanks Mahendra, I am not able to apply the patche against the latest
sources, seems like you need to rebase
On Sat, Dec 6, 2025 at 2:08 AM Bryan Green wrote:
> > I think I'm missing something obvious here. call_string_check_hook
> > doesn't do any memory context management - it just calls the hook.
No, it does do memory management. It has a PG_TRY()/PG_CATCH() block
to ensure that we don't forget to GU
On Monday, December 08, 2025 13:24 MSK, "Zhijie Hou (Fujitsu)"
wrote:
> On Monday, December 8, 2025 5:47 PM Amit Kapila
> wrote:
> > > > Sawada-san/Vitaly, do you have any opinion on patch or the direction
> > > > to fix? The idea is to get this fixed for HEAD and 18, then continue
> > > > dis
Shruthi Gowda writes:
> The ECPG application crashes with a segmentation fault when calling
> specific deallocation or prepared statement functions without an
> established database connection. This is caused by a missing NULL check on
> the connection handle before attempting to access it.
Hmm .
On 12/8/2025 9:23 AM, Bryan Green wrote:
> On 12/6/2025 1:08 AM, Bryan Green wrote:
...
> Actually, I realized I still allocated in CurrentMemoryContext-- I think
> instead I should just allocate the extra_cxt under GUCMemoryContext and
> then there is no need to reparent.
>
> if (conf->flags & GU
On 02.12.25 11:00, Ashutosh Bapat wrote:
When you create future patches, consider using the git format-patch -v
option.
I am still using timestamp as a version but passing it to -v instead
of treating it as a suffix. I like datestamp as versionstamp for the
reasons mentioned upthread.
Date st
On Mon, Dec 08, 2025 at 04:47:17PM +0100, Álvaro Herrera wrote:
> Any objections to these changes?
Nope, LGTM
--
nathan
On Mon, Dec 8, 2025 at 6:32 PM Heikki Linnakangas wrote:
>
> On 06/12/2025 01:36, Heikki Linnakangas wrote:
> > On 05/12/2025 15:42, Ashutosh Bapat wrote:
> >> + $newnode->start;
> >> + my $new_dump = get_dump_for_comparison($newnode, "newnode_${tag}
> >> _dump");
> >> + $newnode->stop;
> >>
> >>
Hello,
Commit 2f698d7f4b7b introduced a message that's a bit different from
others of the same ilk,
+CHECKPOINT (MODE WRONG);
+ERROR: unrecognized MODE option "wrong"
+LINE 1: CHECKPOINT (MODE WRONG);
+^
I'd rather this said
unrecognized value for CHECKPOINT option "mode":
On Sat, Dec 6, 2025 at 5:06 AM Heikki Linnakangas wrote:
> On 05/12/2025 15:42, Ashutosh Bapat wrote:
>
> > 007_multixact_conversion.pl fires thousands of queries through
> > BackgroundPsql which prints debug output for each of the queries. When
> > running this file with oldinstall set,
> > 2.2M
Hi,
The ECPG application crashes with a segmentation fault when calling
specific deallocation or prepared statement functions without an
established database connection. This is caused by a missing NULL check on
the connection handle before attempting to access it.
The issue is reproducible on th
On Mon, 8 Dec 2025 at 15:51, Tom Lane wrote:
>
> Peter Eisentraut writes:
> > AFAICT, both gcc and clang support typeof in C++ mode as well. So this
> > kind of renaming could be confusing.
>
> Hm, if that's true then we should not have to do anything ...
> so why is Jelte reporting a problem?
On Mon, Dec 8, 2025 at 2:46 PM Matthias van de Meent
wrote:
>
> On Fri, 5 Dec 2025 at 16:50, Hannu Krosing wrote:
> >
> > On Fri, Dec 5, 2025 at 3:58 PM Euler Taveira wrote:
> > >
> > > On Thu, Dec 4, 2025, at 5:58 PM, Hannu Krosing wrote:
> > > > Please find attached a patch that makes tuple id
On 12/6/2025 1:08 AM, Bryan Green wrote:
> On 12/5/2025 3:24 PM, Bryan Green wrote:
>> On 12/5/2025 2:48 PM, Robert Haas wrote:
>>> On Fri, Dec 5, 2025 at 12:45 AM Bryan Green wrote:
I tried implementing a PG_TRY/PG_CATCH approach and it doesn't work.
The switch statement in set_config_w
On Fri, 5 Dec 2025 at 17:15, Sami Imseih wrote:
> Hi,
>
> > So, my colleague Ants Aasma found that a wait_event is missing for
> CommitDelay.
> > This just looks like it was missed, please enlighten if it is left out
> intentionally.
>
> I do not know if it was left out intentionally, there are n
Heikki Linnakangas writes:
> On 08/12/2025 10:37, Chao Li wrote:
>> The old patterns are used in a lot of places, and there are some usages
>> of the new pattern as well. Instead of creating a big cleanup patch, I
>> just applied the new pattern to a single file for now to see if the
>> hacker
On Mon, Dec 8, 2025 at 5:56 PM Amit Langote wrote:
>
> On Thu, Dec 4, 2025 at 2:23 AM Ashutosh Bapat
>
> In your commit message:
>
> 4. We have not implemented security definer property graphs since
>SQL/PGQ standard does not mention those.
>
> My reading of the access rules is that, from the
On 05/12/2025 20:09, Heikki Linnakangas wrote:
On 04/12/2025 03:08, Chao Li wrote:
I guess this function doesn’t have to check “-“ by itself, it leads
some edge-case not to be well handled, for example “-0” is still 0,
not a negative value. We can use strtoll() convert input string to a
singed
Peter Eisentraut writes:
> AFAICT, both gcc and clang support typeof in C++ mode as well. So this
> kind of renaming could be confusing.
Hm, if that's true then we should not have to do anything ...
so why is Jelte reporting a problem?
regards, tom lane
On 02.12.25 02:11, Chao Li wrote:
<0001-Use-PG_IO_ALIGN_SIZE-for-aligning-WAL-buffers.patch><0002-Use-PGAlignedXLogBlock-in-BootStrapXLOG.patch><0003-pg_test_fsync-Align-test-data-using-PGAlignedXLogBlo.patch>
Overall the patch looks good to me:
I have committed these all as one patch. Initia
On Fri, 5 Dec 2025 at 16:50, Hannu Krosing wrote:
>
> On Fri, Dec 5, 2025 at 3:58 PM Euler Taveira wrote:
> >
> > On Thu, Dec 4, 2025, at 5:58 PM, Hannu Krosing wrote:
> > > Please find attached a patch that makes tuple ids and info about
> > > weather it was plain or HOT update available to logi
On Fri, Dec 5, 2025 at 6:11 AM Peter Geoghegan wrote:
> On Thu, Dec 4, 2025 at 12:54 AM Amit Langote wrote:
> > I want to acknowledge that figuring out the right layering to make I/O
> > prefetching and perhaps other optimizations internal to IndexNext()
> > work is obviously the priority right n
On Thu, 4 Dec 2025 at 21:58, Hannu Krosing wrote:
>
> Please find attached a patch that makes tuple ids and info about
> weather it was plain or HOT update available to logical decoding
> callbacks.
>
> Also modified test_decoding to show both tids -
> - old tid has format -(pageno, slot)
> - new
On Thu, Dec 4, 2025 at 2:23 AM Ashutosh Bapat
wrote:
> 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".
Hi Chao,
> "gd" is allocated by palloc0, so all members have been zero initialized, thus
> explicitly assigning NULL to the 4 members is unnecessary. I don't think that
> has much runtime impact, but from a readability perspective, a potential
> question is that, "gd" has more fields, why only
On Mon, Dec 8, 2025 at 5:27 PM shveta malik wrote:
>
> On Thu, Dec 4, 2025 at 5:21 PM Shlok Kyal wrote:
> >
> > I have addressed these in the v29 patch.
> > Will address comments for 0003 and 0004 patch by Peter and comments by
> > Shveta in next version.
> >
>
> Thanks for the patch.
>
> I belie
On Mon, Dec 8, 2025 at 12:19 PM Ashutosh Bapat
wrote:
>
> test_decoding output plugin skips sending stream_start and stream_end
> if no change from a segment of a streamed transaction is sent
> downstream. If no change has been sent downstream across all the
> streamed segments it doesn't send com
Hi hackers,
I'd like to propose a new function pg_current_vxact_id() that returns
the
current backend's virtual transaction ID (VXID).
Virtual transaction IDs are fundamental to PostgreSQL's transaction
tracking,
appearing in pg_locks.virtualtransaction, log output via %v placeholder,
and
in
1 - 100 of 135 matches
Mail list logo
