> On Aug 19, 2025, at 23:43, Álvaro Herrera wrote:
>
> On 2025-Aug-19, Chao Li wrote:
>
>> Hi John,
>>
>> Let me explain the Makefile patch in this separate thread, as this is
>> generic to all maps.
>>
>> Let’s not use gb18030 as an example, instead, using utf8_and_win.
>>
>> When any of
On Thu, Oct 9, 2025 at 4:03 PM Michael Paquier wrote:
>
> On Thu, Oct 09, 2025 at 01:36:36PM +1100, Peter Smith wrote:
> > Thanks.
>
> Done this one.
> --
Thanks for pushing!
==
Kind Regards,
Peter Smith.
Fujitsu Australia
Hi,
I saw a sequence replication patch was committed recently [1], so I
was looking at the diffs. Below are a couple of observations:
//
1.
The following message seems overly long:
errmsg("publication parameters are not applicable to sequence
synchronization and will be ignored for seque
Richard Guo wrote:
> On Mon, Oct 6, 2025 at 9:59 AM Richard Guo wrote:
> > On Mon, Sep 29, 2025 at 11:09 AM Richard Guo wrote:
> > > FWIW, I plan to do another self-review of this patch soon, with the
> > > goal of assessing whether it's ready to be pushed. If anyone has any
> > > concerns abo
On Wed, Sep 24, 2025 at 11:57 PM Fujii Masao wrote:
>
> On Wed, Sep 24, 2025 at 12:11 AM Álvaro Herrera wrote:
> >
> > Hello,
> >
> >
> > > /*
> > > - * Check whether the passed slot name is valid and report errors at
> > > elevel.
> > > + * Check whether the passed slot name is valid and repor
On Thu, Oct 09, 2025 at 04:35:55PM +1300, David Rowley wrote:
> On Thu, 9 Oct 2025 at 15:13, Michael Paquier wrote:
> > What do you think about the attached?
>
> Thanks. Looks pretty good.
>
> > + members = palloc(sizeof(int) * num_ops);
>
> Any reason to pfree that and allocate that to the sam
> On Aug 20, 2025, at 11:44, John Naylor wrote:
>
> On Tue, Aug 19, 2025 at 10:43 PM Álvaro Herrera wrote:
>>
>> Also, I suspect you should do something about Meson, but I don't know
>> what that would look like.
>
> It seems to work already on Meson:
>
> $
> $ touch src/backend/utils/mb/U
On Thu, 9 Oct 2025 at 15:13, Michael Paquier wrote:
> What do you think about the attached?
Thanks. Looks pretty good.
> + members = palloc(sizeof(int) * num_ops);
Any reason to pfree that and allocate that to the same size as it already was?
Wondering if the "members[pos] = members[--num_memb
Hi,
On October 8, 2025 10:05:59 PM EDT, Amit Langote
wrote:
>Hi Andres,
>
>On Thu, Oct 9, 2025 at 2:15 AM Andres Freund wrote:
>>
>> Hi,
>>
>> On 2025-10-08 13:39:14 +1300, Thomas Munro wrote:
>> > On Fri, Sep 19, 2025 at 11:44 AM Thomas Munro
>> > wrote:
>> > > On Fri, Sep 19, 2025 at 12:36
Dear Peter, Iwata-san,
> 1a.
> It's not clear to me what you were trying to convey by saying "unless
> slot has been used" in the comment. Maybe you meant "unless slot is
> not in use", but is that useful even to say? Anyway, the comment as-is
> seems incorrect.
Agreed to update the comment. How
On Wed, Oct 8, 2025 at 8:14 PM David Rowley wrote:
> +-- Enable eager aggregation, which by default is disabled.
> +SET enable_eager_aggregate TO on;
> The above comment and command mismatch to my understanding from
> looking at postgresql.conf.sample and guc_parameters.dat.
Right. This GUC was
On Mon, Oct 6, 2025 at 9:59 AM Richard Guo wrote:
> On Mon, Sep 29, 2025 at 11:09 AM Richard Guo wrote:
> > FWIW, I plan to do another self-review of this patch soon, with the
> > goal of assessing whether it's ready to be pushed. If anyone has any
> > concerns about any part of the patch or wou
Hi hackers,
While reviewing pg_createsubscriber in another thread, I found some of
the current logging to be confusing. Specifically, there is one part
that drops all existing publications. Sometimes it might look like
this:
--
pg_createsubscriber: dropping all existing publications in da
On Wed, 8 Oct 2025 17:27:27 -0700
Jeremy Schneider wrote:
> On Thu, 9 Oct 2025 12:59:23 +1300
> David Rowley wrote:
>
> > I believe that is methodology for processing work applies much
> > better in scenarios where there's no new work continually arriving
> > and there's no adverse effects from
On Mon, Oct 6, 2025 at 12:57:20PM -0400, Bruce Momjian wrote:
> On Mon, Oct 6, 2025 at 11:14:13AM -0400, Andres Freund wrote:
> > I'd guess that the *vast* majority of PG workloads these days run on
> > networked
> > block storage. For those typically the actual latency at the storage level
> >
On Sun, Aug 31, 2025 at 12:48 PM Arseniy Mukhin
wrote:
>
> Hi!
>
> On Sun, Aug 31, 2025 at 8:49 PM Andrey Borodin wrote:
> >
> > Hi!
> >
> > > On 31 Aug 2025, at 21:17, Arseniy Mukhin
> > > wrote:
> > >
> > > PFA the patch that migrates BRIN vacuum to the read stream API.
> >
> > The patch is n
Shayon Mukherjee writes:
> Following up on the previous thread - I took a stab at trying to see what a
> full patch for the proposal to reduce lock levels during FK/trigger drops
> would look like, and this is what I ended up with.
I don't think this is safe, at least not for FK removal. There's
Hi,
On 2025-10-08 16:31:13 -0500, Nathan Bossart wrote:
> On Wed, Oct 08, 2025 at 09:41:30PM +0300, Aleksander Alekseev wrote:
> > The main problem here is that clangd is a language server, which means
> > I see errors reported by it when I open a particular file in a text
> > editor. To go manual
On Wed, Oct 8, 2025 at 1:40 PM Andrew Dunstan wrote:
> If we set the default at verify-full (that would be my vote), someone
> can undo that for a particular installation by setting PGSSLMODE=prefer
> globally on their system
I don't think we should ever tell users to set PGSSLMODE=prefer. It's
r
Hi,
On 2025-10-08 22:20:31 +0200, Tomas Vondra wrote:
> On 10/8/25 21:37, Andres Freund wrote:
> > On 2025-10-08 21:25:53 +0200, Tomas Vondra wrote:
> >> On 10/8/25 19:23, Robert Haas wrote:
> I think in the past we mostly assumed we can't track cache size per
> table, because we have no
On 10/8/25 21:37, Andres Freund wrote:
> Hi,
>
> On 2025-10-08 21:25:53 +0200, Tomas Vondra wrote:
>> On 10/8/25 19:23, Robert Haas wrote:
I think in the past we mostly assumed we can't track cache size per
table, because we have no visibility into page cache. But maybe direct
I/
On 10/8/25 19:23, Robert Haas wrote:
> On Wed, Oct 8, 2025 at 12:24 PM Tomas Vondra wrote:
>> I don't think there's all that much disagreement, actually. This is a
>> pretty good illustration that we're using random_page_cost to account
>> for things other than "I/O cost" (like the expected cac
Hi,
On 2025-10-08 21:12:37 +0200, Tomas Vondra wrote:
> I did a run on PG17 (on the NVMe RAID), and it's not all that different
> from PG18:
>
> seqscan (s) index scan (s) random_page_cost
> -
> PG18 NVMe/RAI
On 10/8/25 12:01, Tomas Vondra wrote:
> On 10/8/25 06:02, David Rowley wrote:
>> On Wed, 8 Oct 2025 at 08:15, Greg Sabino Mullane wrote:
>>> I've been doing this sort of thing for clients a long time, and I always
>>> test both directions when I come across a query that should be faster. For
On Oct 8 2025, at 8:10 am, Ranier Vilela wrote:
> Hi.
>
>
>> Em sex., 3 de out. de 2025 às 09:13, Greg Burd escreveu:
>>
>>>
>>> On Oct 3 2025, at 4:25 am, Daniel Gustafsson wrote:
>>>
> On 3 Oct 2025, at 01:36, David Rowley wrote:
>
> On Fri, 3 Oct 2025 at 01:33, Dani
> Not saying that the current approach, which is as you mention is
> random, is any better, however this approach will likely increase
> the behavior of large tables saturating workers.
Maybe it will be good to allocate some workers to the oldest tables
and workers based on some random list? This
On 2025-Oct-08, Sami Imseih wrote:
> One risk I see with this approach is that we will end up autovacuuming
> tables that also take the longest time to complete, which could cause
> smaller, quick-to-process tables to be neglected.
Perhaps we can have autovacuum workers decide on a mode to use at
Thanks for raising this topic! I agree that autovacuum scheduling
could be improved.
> * Prioritizing tables based on their (M)XID age might help avoid more
> aggressive vacuums, not to mention wraparound. Of course, there are
> scenarios where this doesn't work. For example, the age of a table
We just witnessed something weird with a patch that's perhaps a bug in
the workflow for detecting attachments. Patch in question was
https://commitfest.postgresql.org/patch/5972/
1. patch was in CF19-2
2. patch needed rebase.
3. Mario sent a new mail with rebased git-format-patch to the thread
4.
On Tue, Oct 7, 2025 at 3:15 PM Greg Sabino Mullane wrote:
> I've been doing this sort of thing for clients a long time, and I always test
> both directions when I come across a query that should be faster. For
> real-world queries, 99% of them have no change or improve with a lowered rpc,
> and
On Wed, Oct 8, 2025, at 05:43, Chao Li wrote:
> After several rounds of reviewing, the code is already very good. I
> just got a few small comments:
Thanks for feedback!
The below changes have been incorporated into the v12 version
sent in my previous email.
>> On Oct 8, 2025, at 03:26, Joel Ja
On Mon, Oct 6, 2025 at 2:06 PM Jacob Champion
wrote:
> I want to move towards a world where we have sslmode=verify-full by
> default. (And maybe gssencmode=disabled, for that matter.) But
> changing defaults is risky for established users.
>
> I'm exploring the idea of a global configuration for l
> clangd indicates that certain #include's are redundant. Removing them
> will speed up the build process a bit.
OK, cfbot tells me that touching collationcmds.c was a mistake. Here
is a corrected patch.
--
Best regards,
Aleksander Alekseev
From b1c7b1db0248be57cda809a69794c49efb9f69fd Mon Sep 1
On 2025-Oct-09, David Rowley wrote:
> On Thu, 9 Oct 2025 at 00:36, Álvaro Herrera wrote:
> > Yeah, that change makes sense to me. With an eye towards not forcing
> > the translators to understand the message context or forced to translate
> > the word "parallel", I would suggest to take the opti
Hi,
A recent run of CI on master had this failure:
https://cirrus-ci.com/task/5786871604707328
on master, for openbsd.
regress log:
https://api.cirrus-ci.com/v1/artifact/task/5786871604707328/testrun/build/testrun/subscription/022_twophase_cascade/log/regress_log_022_twophase_cascade
server
Hi,
clangd indicates that certain #include's are redundant. Removing them
will speed up the build process a bit.
--
Best regards,
Aleksander Alekseev
From 812f9bce0369596040b6036d090f3075b4240771 Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Wed, 8 Oct 2025 15:58:38 +0300
Subject: [P
On Wed, Oct 08, 2025 at 05:29:20PM +1100, Peter Smith wrote:
> It didn't look right to me.
>
> I found the code is doing:
> - pg_log_info("creating the replication slot unconditional inside
> create_logical_replication_slot
> - pg_log_info("create replication slot...") immediately after call to
>
On Mon, Oct 06, 2025 at 01:25:12PM +0700, Alena Vinter wrote:
> Michael, thanks for helping! This fact simplifies the code. I put resetting
> the parameters exclusively in the `atexit` callback -- this approach seems
> neater to me. What do you think?
I have been looking at this patch for a couple
Hi,
On Thu, Sep 25, 2025 at 4:12 AM Rishu Bagga wrote:
>
> Hello all,
creating a new thread here in continuation of [1], as the patch
> has changed direction significantly from the subject there.
There are a lot of improvements, thank you for the new version! I'm
still in the process of reviewi
On Wed, Oct 8, 2025 at 2:41 PM Dilip Kumar wrote:
>
> On Tue, Oct 7, 2025 at 4:52 PM vignesh C wrote:
> >
> > On Tue, 7 Oct 2025 at 12:09, Amit Kapila wrote:
> > >
>
> I think the patch is mostly LGTM, I have 2 suggestions, see if you
> think this is useful.
>
> 1.
> postgres[1390699]=# CREATE P
Hi Oliver,
After studying the standard more, it seems I was totally wrong.
In summary, current code is correct. Sorry for noise.
>From the standard explaining lead():
> B) If OFFSET = 0 (zero), then the value of is the
> value of VE1 evaluated for the current row.
(here VE1 referes to the first
41 matches
Mail list logo
