> On Nov 19, 2025, at 12:14, Chao Li wrote:
>
>
> 9 - 0002 - parse_clause.c
I am continuing to review 0003
10 - 0003
```
+ Assert(list_length(patternVariables) == list_length(defineClause));
```
Is this assert true? From what I learned, pattern length doesn’t have to equal
to define
On Mon, Nov 17, 2025 at 9:50 PM Amit Langote wrote:
> On Wed, Nov 12, 2025 at 11:17 PM Amit Langote wrote:
> > * Enable pruning-aware locking in cached / generic plan reuse (0004):
> > extends GetCachedPlan() and CheckCachedPlan() to call ExecutorPrep()
> > on each PlannedStmt in the CachedPlan,
> I'd +1 for triggered_by over just trigger, but I actually think
> triggered_by should be avoided as well for the same reason (term
> overload). We already use the verb "launch" as the word to describe
> this action in the existing autovacuum docs, but I was unable to come
> up with something that
On Thu, Nov 20, 2025 at 3:03 AM Aleksander Alekseev
wrote:
> Thanks for working on this. I checked v2 on Linux x64 with and without
> Valgrind and it passed all the tests. I haven't looked at the code
> closely yet.
Thanks for testing!
The next thing on my TODO list for this is some kind of code
On Thu, Nov 20, 2025 at 12:23 AM Peter Eisentraut wrote:
> 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]
On Wed, Nov 19, 2025 at 8:46 PM Fujii Masao
wrote:
> How about using PGC_USERSET instead of PGC_SIGHUP, similar to
> wal_sender_timeout?
Dear Fujii, thanks for the review!
Current version of the patch suggests changing the shutdown mode of
logical senders globally for the server. As I wrote abo
Hi
Perhaps you haven't seen my previous post.
> > FWIW, while reading this code, I was wondering about one improvement
> > that could show benefits for more extension code than only what we are
> > discussing here because external code has no access to
> > BackgroundWorkerSlot while holding the L
On Thu, Nov 20, 2025 at 9:35 AM Shinya Kato wrote:
> On Wed, Nov 19, 2025 at 4:56 PM Maciek Sakrejda wrote:
> > On Tue, Nov 18, 2025, 21:10 Shinya Kato wrote:
> >> On Wed, Nov 19, 2025 at 9:04 AM Masahiko Sawada
> >> > > Fixed, but I have a comment. I noticed
> >> minor wording inconsistencies,
Quick correction with an apology: I accidentally created a new thread
(https://www.postgresql.org/message-id/tencent_64301BB7627E58CD256CE15F%40qq.com)
and submitted the patch there—my apologies for the mix-up! Let’s just continue
the discussion here as planned.
--
Regrads,
Man Zeng
> On Nov 18, 2025, at 23:59, Fujii Masao wrote:
>
> Hi,
>
> In logical replication, any GUC settings specified in the CONNECTION clause of
> CREATE SUBSCRIPTION are currently ignored. For example:
>
>CREATE SUBSCRIPTION mysub
>CONNECTION 'options=''-c wal_sender_timeout=1
Hello everyone,
I have tested the v4 patch and observed that the following scenario requires
support. Accordingly, I have prepared version v5: v5-0001 is fully consistent
with the v4 patch, and v5-0002 restricts input to domains exclusively, with an
additional simple test case attached.
```sq
Hi Shlok.
Thanks for splitting the patches.
Here are some review comments for the new patch v28-0002 (ADD ALL TABLES).
==
Commit Message
1.
This patch adds support for using ADD ALL TABLES in ALTER PUBLICATION,
allowing an existing publication to be changed into an ALL TABLES
publication. T
On Thu, Nov 20, 2025 at 10:34 AM Sami Imseih wrote:
>
> Hi,
>
> The patch looks overall good to me. I have a few comments:
Thank you for your review!
> 1/ I believe It is possible for the mode to flip to "failsafe" during the
> operation since lazy_check_wraparound_failsafe() is checked in-fligh
Hello,
Thomas Munro, le mar. 18 nov. 2025 18:32:38 +1300, a ecrit:
> On Tue, Nov 18, 2025 at 12:31 PM Samuel Thibault
> > > Possibly too private/undocumented anyway,
> >
> > It's not really documented much, but it's completely public. One
> > can include and call e.g. io_read_request(port,
> > re
31.10.2025 2:10, Masahiko Sawada wrote:
---
I think we should update the documentation in the uuid section about
casting data between bytea and uuid. For references, we have a similar
description for bytea and integer[1].
Greetings!
I briefly tested the patched version of v3. The implemented
fun
On Wed, Nov 19, 2025 at 10:08 PM Dean Rasheed wrote:
>
> The latest set of changes look reasonable to me, so I've squashed
> those 2 commits together and made an initial stab at writing a more
> complete commit message.
>
hi.
"Note that exclusion constraints are not supported as arbiters with ON
On Thursday, November 20, 2025 5:31 AM Tomas Vondra wrote:
>
> Hello Kuroda-san,
>
> On 11/18/25 12:00, Hayato Kuroda (Fujitsu) wrote:
> > Dear Amit,
> >
> >> It seems you haven't sent the patch that preserves commit order or the
> >> commit message of the attached patch is wrong. I think the fi
> Should we suggest "MERGE INTO" instead of just "MERGE",
> since INTO always follows MERGE?
>
> Also, how about adding "TABLE" and "WITH" to the suggestions,
> similar to the tab-completion for "COPY ("?
> SELECT statement can be specified in the PREPARE command,
> and it can start with SELECT, TA
On Wed, Nov 19, 2025 at 7:56 PM Dagfinn Ilmari Mannsåker
wrote:
>
> > v3 goes back to v1 plus I add a check for unknown field type per your
> > suggestion, for example:
> > ```
> > error: guc_parameters.data line 2271: unknown GUC type 'intt'
> > ```
>
> We've already validated that the name fiel
Hi Tatsuya,
I just ran a test against v3.
> On Nov 20, 2025, at 01:30, 河田達也 wrote:
>
>
> I also removed the unintended blank lines and ran pgindent as you suggested.
> I appreciate your continued feedback, and I would be grateful for another
> review of the v3 patch.
>
> Best regards,
> Tats
On Thu, Nov 20, 2025 at 11:45 AM Samuel Thibault
wrote:
> Thomas Munro, le mar. 18 nov. 2025 18:32:38 +1300, a ecrit:
> > Does that also imply that preadv() has to loop over the vectors
> > sending tons of messages and waiting for replies?
>
> Currently glibc's preadv performs copies.
Even withou
On Thu, Nov 20, 2025 at 2:06 PM Chao Li wrote:
>
>
>
> > On Nov 20, 2025, at 09:41, Peter Smith wrote:
> >
> > On Thu, Nov 20, 2025 at 12:03 PM Fujii Masao wrote:
> >>
> >> On Thu, Nov 20, 2025 at 9:02 AM Chao Li wrote:
> >>> V6 looks better.
> >>
> >> +1. Thanks for updating the patch!
> >>
>
> On Nov 19, 2025, at 23:37, Heikki Linnakangas wrote:
>
> 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 c
> On Nov 20, 2025, at 09:41, Peter Smith wrote:
>
> On Thu, Nov 20, 2025 at 12:03 PM Fujii Masao wrote:
>>
>> On Thu, Nov 20, 2025 at 9:02 AM Chao Li wrote:
>>> V6 looks better.
>>
>> +1. Thanks for updating the patch!
>>
>> +and table is:
>> +
>> +[ ONLY ] table_name [ * ]
>>
>> I h
> On Nov 20, 2025, at 06:12, Melanie Plageman wrote:
>
> Are you sure you applied 0005? It is the one that adds dbId to CkptSortItem.
>
My bad. Yes, I missed to download and apply 0005.
> - Melanie
>
I went through the whole patch set again, and got a few more comments:
1 - 0002
```
+/*
On 11/19/25 12:52 PM, Christoph Berg wrote:
Re: Álvaro Herrera
I didn't immediately love this idea, but I'm not totally opposed to it
either, and perhaps it makes things better rather than adding yet
another very narrowly-focused tool. Also, pg_ctl already kinda has a
somewhat similar facet wit
It just occurred to me that the documentation [0] should be
updated to describe the callbacks. I will do that in the next
revision.
[0]
https://www.postgresql.org/docs/current/xfunc-c.html#XFUNC-ADDIN-CUSTOM-CUMULATIVE-STATISTICS
--
Sami Imseih
Amazon Web Services (AWS)
Hi Shlok,
Some review comments for patch v28-0001.
==
src/backend/commands/publicationcmds.c
AlterPublicationReset:
1.
+ values[Anum_pg_publication_puballtables - 1] =
BoolGetDatum(PUB_DEFAULT_ALL_TABLES);
+ replaces[Anum_pg_publication_puballtables - 1] = true;
+
+ values[Anum_pg_publicatio
On 2025-11-20 02:23, Robert Haas wrote:
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
On Thu, Nov 20, 2025 at 9:27 AM Tom Lane wrote:
>
> Heikki's draft commit message addresses that point:
>
> The old implementation accepted trailing whitespace, but that seemed
> unnecessary. Firstly, its sibling function for parsing decimals,
> strtodouble(), does not accept trailing
On Thu, Nov 20, 2025 at 12:03 PM Fujii Masao wrote:
>
> On Thu, Nov 20, 2025 at 9:02 AM Chao Li wrote:
> > V6 looks better.
>
> +1. Thanks for updating the patch!
>
> +and table is:
> +
> +[ ONLY ] table_name [ * ]
>
> I have one question: in lock.sgml and truncate.sgml, the syntax
> "[ ONLY
On Wed, 19 Nov 2025 at 16:36, Akshay Joshi
wrote:
> 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
Hi,
The patch looks overall good to me. I have a few comments:
1/ I believe It is possible for the mode to flip to "failsafe" during the
operation since lazy_check_wraparound_failsafe() is checked in-flight.
I think this should be mentioned in the "mode" section of the documentation
in the "fails
On 11/19/25 8:06 PM, Marko Tiikkaja wrote:
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-f25
Neil Chen writes:
> +1 on this simplification – it definitely makes the code cleaner.
> One small note: the updated code doesn’t handle trailing spaces in the
> input string. Should we consider this a concern?
Heikki's draft commit message addresses that point:
The old implementation accepte
I wrote:
> The main thing that's likely wrong here is that I just manually
> shoved a new entry into src/backend/po/es.po. I suspect that
> the .po-extraction machinery would fail to pick up that string
> because it's in src/test/regress/regress.c. We could hack it
> to do that, or we could put t
Hi,
On Thu, Nov 20, 2025 at 8:57 AM Heikki Linnakangas wrote:
> Here's a small patch to replace the int64 parsing code in pgbench with a
> call to strtoi64(). Makes it a little simpler.
>
>
+1 on this simplification – it definitely makes the code cleaner.
One small note: the updated code doesn’t
On Thu, Nov 20, 2025 at 9:02 AM Chao Li wrote:
> V6 looks better.
+1. Thanks for updating the patch!
+and table is:
+
+[ ONLY ] table_name [ * ]
I have one question: in lock.sgml and truncate.sgml, the syntax
"[ ONLY ] name [ * ] [, ... ]" seems shown as acceptable (though
I'm not entirely
On Thu, Nov 20, 2025 at 11:02 AM Chao Li wrote:
>
>
>
> > On Nov 20, 2025, at 06:18, Peter Smith wrote:
> >
> > Hi Fuji-San.
> >
> > Thanks for your suggestions! I've attached a new patch v6 to incorporate
> > them.
> >
> > On Thu, Nov 20, 2025 at 4:50 AM Fujii Masao wrote:
> >>
> >> On Tue, N
Hi Heikki:
On Thu, Nov 20, 2025 at 8:45 AM Heikki Linnakangas wrote:
> 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 pro
On Wed, Nov 19, 2025 at 6:55 PM Corey Huinker
wrote:
> On Wed, Nov 19, 2025 at 5:44 PM Nathan Bossart
> wrote:
>
>> On Wed, Nov 19, 2025 at 05:23:48PM -0500, Corey Huinker wrote:
>> > Now with zero hangs and some test cases. I didn't create a function
>> (yet)
>> > as it seemed trivial.
>>
>> I
On Wed, Nov 19, 2025 at 4:56 PM Maciek Sakrejda wrote:
>
> On Tue, Nov 18, 2025, 21:10 Shinya Kato wrote:
>>
>> On Wed, Nov 19, 2025 at 9:04 AM Masahiko Sawada
>> > > Fixed, but I have a comment. I noticed
>> minor wording inconsistencies,
>> > > e.g., 'started' vs. 'initiated' and 'due to' vs.
On Wed, Nov 19, 2025 at 10:51 PM Fujii Masao wrote:
>
> 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.
I've p
On Wed, Nov 19, 2025 at 9:31 AM 河田達也 wrote:
>
> 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.
+1
>
> ---
> >+ /* Report memor
On Wed, Nov 19, 2025 at 11:19 PM Daniel Gustafsson wrote:
>
> > On 19 Nov 2025, at 15:17, Fujii Masao wrote:
>
> > So I will commit v3 patch.
>
> +1
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
> On Nov 20, 2025, at 06:18, Peter Smith wrote:
>
> Hi Fuji-San.
>
> Thanks for your suggestions! I've attached a new patch v6 to incorporate
> them.
>
> On Thu, Nov 20, 2025 at 4:50 AM Fujii Masao wrote:
>>
>> On Tue, Nov 18, 2025 at 5:27 PM Chao Li wrote:
>>> Thanks for addressing the
On Wed, Nov 19, 2025 at 5:44 PM Nathan Bossart
wrote:
> On Wed, Nov 19, 2025 at 05:23:48PM -0500, Corey Huinker wrote:
> > Now with zero hangs and some test cases. I didn't create a function (yet)
> > as it seemed trivial.
>
> I still think it could be worth moving the dry-run code into
> run_vac
On Tue, Nov 18, 2025 at 2:13 PM Matheus Alcantara
wrote:
>
> On Mon Nov 17, 2025 at 11:03 PM -03, Masahiko Sawada wrote:
> > IIUC the performance regression occurs when users insert many rows
> > into a foreign table with batch_size = 1 and use_copy_for_insert =
> > true (tps: 133.451518 vs. 132.6
On Thu, 20 Nov 2025 at 10:58, Bruce Momjian wrote:
> I think you are right. Attached is the difference between the output
> for 16 & 17. Let me do some more research and run all the versions
> again and report back, thanks.
Maybe you'd be better with git ls-files if you only want just what's
in
On Thu, Nov 13, 2025 at 7:17 PM Ajin Cherian wrote:
>
> On Thu, Nov 13, 2025 at 8:49 AM Masahiko Sawada wrote:
> >
> > On Mon, Nov 10, 2025 at 7:37 PM Ajin Cherian wrote:
> > >
> > > On Tue, Nov 11, 2025 at 2:19 PM Amit Kapila
> > > wrote:
> > > >
> > > > In the commit message, you mentioned:
On Wed, Nov 19, 2025 at 1:52 AM Jim Jones wrote:
>
> Hi Chao
>
> On 19/11/2025 04:13, Chao Li wrote:
> > 1. Do we need to perform some privilege check? I just did a test:
> > ```
> > evantest=> \c
> > You are now connected to database "evantest" as user "evan".
> > evantest=> select pg_get_tables
On Thu, Nov 20, 2025 at 11:23 AM Tom Lane wrote:
> I'm also unsure if this will work as-is on Windows;
> are the LC_MESSAGES settings the same there?
Bilal [CC'd], have you ever looked into gettext support for Windows
CI? I think we'd need at least msgfmt.exe, libintl.{dll,lib,h}
installed on th
On Wed, Nov 19, 2025 at 05:23:48PM -0500, Corey Huinker wrote:
> Now with zero hangs and some test cases. I didn't create a function (yet)
> as it seemed trivial.
I still think it could be worth moving the dry-run code into
run_vacuum_command() (which might entail moving the calls to
ParallelSlotS
On Tue, Nov 18, 2025 at 8:46 PM Chao Li wrote:
>
>
> When XLogNeedsFlush(lsn) is true, StrategyRejectBuffer returns false, thus no
> retry will happen, which is different from the old logic, is that an
> intentional change?
No, this is a mistake. You are correct. I thought I had fixed this in
a
>
> > 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 pro
I wrote:
> I agree with the idea of just using a single test message that checks
> all the PRI* macros we care about. I don't think we need to invent a
> whole new translation for this. I'd be inclined to just get the
> desired translated string pushed into one or two .po files in HEAD,
> then we
Hi Fuji-San.
Thanks for your suggestions! I've attached a new patch v6 to incorporate them.
On Thu, Nov 20, 2025 at 4:50 AM Fujii Masao wrote:
>
> 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 revie
Thanks for the review!
On Tue, Nov 18, 2025 at 9:10 PM Chao Li wrote:
>
> > On Nov 19, 2025, at 10:00, Chao Li wrote:
>
> > I just reviewed 0007. It removes the second parameter "bool
> > skip_recently_used” from SyncOneBuffer. The function is static and is only
> > called in one place with s
On 2025-Nov-19, Robert Haas wrote:
> I do not know how to make the phrase "older minor releases" any more
> clear.
It's perfectly clear. I just don't believe this claim.
> You and Álvaro seem to be under the impression that nobody will
> ever try to compile code written after this change from a
On 2025-Nov-19, Tom Lane wrote:
> > No, I just followed the shell comment I wrote above the 'find' command
> > shown above:
>
> > # This script is used to compute the total number of "C" lines in the
> > # release This should be run from the top of the Git tree after a 'make
> > # dis
On Wed, Nov 19, 2025 at 04:22:37PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Nov 19, 2025 at 03:21:33PM -0500, Tom Lane wrote:
> >> Also ... are you in fact counting only what is in git? Because
> >> I get different answers:
>
> > No, I just followed the shell comment I wrote ab
On Tue Nov 18, 2025 at 4:14 AM -03, Alexander Pyhalov wrote:
> Updated the first patch.
>
Thanks for the new version. Some new comments.
v7-0002-MergeAppend-should-support-Async-Foreign-Scan-subpla.patch:
1. Should be "nasyncplans" instead of "nplans"? ExecInitAppend use
"nasyncplans" to allocate
On Tue, Nov 18, 2025 at 10:27 PM Amit Kapila wrote:
>
> On Wed, Nov 19, 2025 at 6:26 AM Masahiko Sawada wrote:
> >
> > On Tue, Nov 18, 2025 at 1:30 AM Amit Kapila wrote:
> > >
> > > On Sat, Nov 15, 2025 at 4:02 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Fri, Nov 14, 2025 at 2:39 AM Ami
Hello Kuroda-san,
On 11/18/25 12:00, Hayato Kuroda (Fujitsu) wrote:
> Dear Amit,
>
>> It seems you haven't sent the patch that preserves commit order or the
>> commit message of the attached patch is wrong. I think the first patch
>> in series should be the one that preserves commit order and the
Thomas Munro writes:
> On Thu, Nov 20, 2025 at 6: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.
> Oh, that's probably better tha
Bruce Momjian writes:
> On Wed, Nov 19, 2025 at 03:21:33PM -0500, Tom Lane wrote:
>> Also ... are you in fact counting only what is in git? Because
>> I get different answers:
> No, I just followed the shell comment I wrote above the 'find' command
> shown above:
> # This script is used t
Hello,
At Materialize we observed a strange behavior of walsender during logical
replication where it sends a flood of keepalive messages to the subscriber
when the database walsender is running on is itself syncing a large table
from another unrelated database.
The setup that reproduces the prob
Hi,
I have been following these discussions but not read the patch in detail.
This patch makes me worried especially with the new issues recently
uncovered. This was already a quite big patch and to fix these issues it
will likely have to become even bigger and given how this would become a
v
On Thu, Nov 20, 2025 at 6: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.
Oh, that's probably better than my nearby en.po + es.po sug
On Tue, Nov 18, 2025 at 05:20:05PM +0300, Nazir Bilal Yavuz wrote:
> Thanks, done.
I took a look at the v3 patches. Here are my high-level thoughts:
+/*
+ * Parse data and transfer into line_buf. To get benefit from inlining,
+ * call CopyReadLineText() with the constant boolean vari
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
1 - 100 of 162 matches
Mail list logo
