On Saturday, May 3, 2025, Masahiko Sawada wrote:
> On Sat, May 3, 2025 at 7:42 AM David G. Johnston
> wrote:
> >
> > On Saturday, May 3, 2025, Masahiko Sawada wrote:
> >
> >>
> >> I think that we need to ensure that if users specify text/csv/binary
> >> the built-in formats are always used, to
On Sat, May 3, 2025 at 7:42 AM David G. Johnston
wrote:
>
> On Saturday, May 3, 2025, Masahiko Sawada wrote:
>
>>
>> I think that we need to ensure that if users specify text/csv/binary
>> the built-in formats are always used, to keep backward compatibility.
>
>
> That was my original thinking, b
jian he writes:
> we have two commits,
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=d6dd2a02bae0d67ff6fbd73068dc36d0b82fc14b
> and
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=bd178960c69bae972c274af8102da9018df8196a
> we should include both commit's authors...
Argh
On Sat, May 3, 2025 at 12:39 AM Tom Lane wrote:
>
> Much less exciting than the v18 release notes, but we
> still gotta do 'em. See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=176877f461a8b55e921f597fb217f6ab89ee019f
>
> As usual, please send corrections by Sunday.
>
+
On Sun, May 4, 2025 at 02:48:31AM +0300, Alexander Borisov wrote:
> 04.05.2025 02:28, Bruce Momjian wrote:
>
>
> > It doesn't warrant its own item because it is not user-facing work. The
> > best we can do is add the commit to an existing item and add you as a
> > co-author on an existing item.
04.05.2025 02:28, Bruce Momjian wrote:
It doesn't warrant its own item because it is not user-facing work. The
best we can do is add the commit to an existing item and add you as a
co-author on an existing item. You will see several items that are that
way already.
Thank you for clarifying
On Sun, May 4, 2025 at 02:24:16AM +0300, Alexander Borisov wrote:
> 04.05.2025 01:47, Bruce Momjian wrote:
>
> [...]
>
> > Given the performance numbers above, which were not in the commit, maybe
> > I should add it to the case folding item, and add his name as a
> > co-author.
> >
>
> I'm not
04.05.2025 01:47, Bruce Momjian wrote:
[...]
Given the performance numbers above, which were not in the commit, maybe
I should add it to the case folding item, and add his name as a
co-author.
I'm not a co-author, I'm the author of my own algorithm that
significantly improves PostgreSQL code
On Sun, May 4, 2025 at 01:31:51AM +0300, Alexander Borisov wrote:
> Hi hackers,
>
> > I will continue improving it until beta 1, and until the final release.
> > I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
> >
> > You can see the most current HTML-built version here:
>
On Sat, May 3, 2025 at 09:40:47PM +0200, Jelte Fennema-Nio wrote:
> On Sat, 3 May 2025 at 18:19, Bruce Momjian wrote:
> > I moved the item and added some text, patch attached.
>
> LGTM, apart from the typo in the word "client' (it's spelled as
> "cliient" in the diff).
Thanks, fixed.
> Noticed
Hi hackers,
I will continue improving it until beta 1, and until the final release.
I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
You can see the most current HTML-built version here:
https://momjian.us/pgsql_docs/release-18.html
I'm not sure, but I'll ask.
Hello,
On 2025-May-03, Tanin Na Nakorn wrote:
> Hi hackers,
>
> I've made a proof of concept for pg_dump to support "on conflict do update"
> here: https://github.com/tanin47/postgres/pull/1
Please post as a patch attachment on the list. We don't take patches
from third party sites. Thanks.
That's reasonable. Thank you.
On Sat, May 3, 2025 at 12:31 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sat, May 3, 2025 at 12:08 PM Tanin Na Nakorn
> wrote:
>
>> 3. Is it possible to patch this into the version 16 as well as the
>> version 17 and latest main branch? Because I
On Sat, May 3, 2025 at 12:08 PM Tanin Na Nakorn wrote:
> 3. Is it possible to patch this into the version 16 as well as the version
> 17 and latest main branch? Because I use v16.
>
>
New features are never back-ported into prior versions. Feature freeze for
v18 just happened meaning any new fea
On Sat, 3 May 2025 at 18:19, Bruce Momjian wrote:
> I moved the item and added some text, patch attached.
LGTM, apart from the typo in the word "client' (it's spelled as
"cliient" in the diff).
Noticed a few other small things when rereading:
1. "Add libpq functions and environment..." should b
Hi hackers,
I've made a proof of concept for pg_dump to support "on conflict do update"
here: https://github.com/tanin47/postgres/pull/1
It can be used with the following options: --on-conflict-target-columns
url,payload_checksum
--on-conflict-update-clause='last_used_at=EXCLUDED.last_used_at'
I
On 28/3/2025 14:09, Robert Haas wrote:
On Thu, Mar 27, 2025 at 5:34 PM Andrei Lepikhov wrote:
I’m afraid to sound like a bore, but I think pg_overexplain should
include a call into the hook call chain (see attachment). Who knows,
maybe this extension will be used someday in production?
Oh, bo
BF member mule just showed what seems an identical failure [1]:
2025-05-03 17:46:20.088 CEST [24308:3] LOG: database system is ready to accept
read-only connections
2025-05-03 17:46:20.091 CEST [24321:1] LOG: slot sync worker started
2025-05-03 17:46:20.100 CEST [24322:1] LOG: started streamin
On Sat, May 3, 2025 at 11:04:45PM +0800, jian he wrote:
> On Fri, May 2, 2025 at 10:44 AM Bruce Momjian wrote:
> >
> > I have committd the first draft of the PG 18 release notes. The item
> > count looks strong:
> > release-17: 182
> > release-18: 209
> >
> > I will continue
On Sat, May 3, 2025 at 01:16:24PM +0200, Jelte Fennema-Nio wrote:
> On Sat, 3 May 2025 at 02:06, Bruce Momjian wrote:
> >
> > On Sat, May 3, 2025 at 01:46:29AM +0200, Jelte Fennema-Nio wrote:
> > > On Fri, 2 May 2025 at 04:45, Bruce Momjian wrote:
> > > >
> > > > I have committd the first draft
While responding to a "our documentation is buggy" complaint I got annoyed
in my attempt to reproduce the behavior by having to surgically copy
line-by-line the DDL and DML code involved. Let's strive for a more
copy-paste friendly example setup. No prompts and no interspersed command
tags (they
On Thu, May 1, 2025 at 10:19 PM jian he wrote:
>
> hi.
>
> catalog.sgml:
>
>
>
>convalidated bool
>
>
>Has the constraint been validated?
>Currently, can be false only for foreign keys and CHECK constraints
>
>
>
> with NOT NULL NOT V
On Fri, May 2, 2025 at 10:44 AM Bruce Momjian wrote:
>
> I have committd the first draft of the PG 18 release notes. The item
> count looks strong:
> release-17: 182
> release-18: 209
>
> I will continue improving it until beta 1, and until the final release.
> I will probably
Re: Jacob Champion
> So, committed. Thanks everyone for all the excellent feedback!
The package split between libpq5 and libpq-oauth in Debian has already
been accepted into the experimental branch.
Thanks,
Christoph
On Saturday, May 3, 2025, Masahiko Sawada wrote:
> I think that we need to ensure that if users specify text/csv/binary
> the built-in formats are always used, to keep backward compatibility.
That was my original thinking, but it’s inconsistent with how functions
behave today. We don’t promis
On 2025-May-01, Tender Wang wrote:
> Hmm. I didn't get the same conclusion.
> Before commit 5914a22f6ea5, the issue reported by Luca could have happened.
[...]
> You can see from the above test that no error was reported.
> But if I revert the commit 614a406b4ff1, above test would report error o
On Sun, Apr 6, 2025 at 8:35 PM Etsuro Fujita wrote:
> I will push the patch as well.
I pushed this one too.
Thanks!
Best regards,
Etsuro Fujita
On Sat, 3 May 2025 at 02:06, Bruce Momjian wrote:
>
> On Sat, May 3, 2025 at 01:46:29AM +0200, Jelte Fennema-Nio wrote:
> > On Fri, 2 May 2025 at 04:45, Bruce Momjian wrote:
> > >
> > > I have committd the first draft of the PG 18 release notes. The item
> > > count looks strong:
> >
> > Thanks
On Mon, Apr 7, 2025 at 6:50 PM Etsuro Fujita wrote:
> On Sun, Apr 6, 2025 at 11:44 PM Michael Paquier wrote:
> > Could you also backpatch that down to v15? It
> > would be good to keep this level of comment documentation consistent
> > across all branches.
>
> Sure, I will do that as well.
Push
> On May 1, 2025, at 16:33, Richard Guo wrote:
>
> Here is the patchset that implements this optimization. 0001 moves
> the expansion of virtual generated columns to occur before sublink
> pull-up. 0002 introduces a new function, preprocess_relation_rtes,
> which scans the rangetable for rel
On Sat, May 3, 2025 at 5:59 AM Sami Imseih wrote:
>
> > I think it would more make
> > sense to maintain the existing autovacuum_max_workers parameter while
> > introducing a new parameter that would either control the maximum
> > number of parallel vacuum workers per autovacuum worker or set a
>
On Sat, May 3, 2025 at 5:28 AM Masahiko Sawada wrote:
>
> > In current implementation, the leader process sends a signal to the
> > a/v launcher, and the launcher tries to launch all requested workers.
> > But the number of workers never exceeds `autovacuum_max_workers`.
> > Thus, we will never ha
On Fri, May 2, 2025 at 11:37 PM David G. Johnston
wrote:
>
> On Friday, May 2, 2025, Masahiko Sawada wrote:
>>
>>
>> I'm concerned about allowing multiple 'text' format implementations
>> with identical names within the database, as this could lead to
>> considerable confusion. When users specify
On Sat, May 3, 2025 at 3:17 AM Sami Imseih wrote:
>
> I think in most cases, the user will want to determine the priority of
> a table getting parallel vacuum cycles rather than having the autovacuum
> determine the priority. I also see users wanting to stagger
> vacuums of large tables with many
34 matches
Mail list logo
