Hi,
On Mon, May 05, 2025 at 03:07:01PM -0400, Jonathan S. Katz wrote:
> Hi,
>
> Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
Thanks for working on it!
One small feedback on this:
"
and now shows per-connection statistics on I/O utilization
"
I think we can add WAL to
On Sat, May 3, 2025 at 1:18 AM Bruce Momjian wrote:
> On Fri, May 2, 2025 at 01:00:57PM +0900, Amit Langote wrote:
> > 1. Speed up execution of cached plans by deferring locks on partitions
> > subject to pruning (Amit Langote)
> > (bb3ec16e1, d47cbf474, cbc127917, 525392d57)
> >
> > 2. Speed up
On Mon, May 5, 2025 at 11:39 AM David G. Johnston
wrote:
>
> On Sun, May 4, 2025 at 8:45 PM Nisha Moond wrote:
>>
>> Attached is the patch implementing the above proposed solution.
>> Reviews and feedback are most welcome.
>
>
> I feel like this is just papering over the issue - which is that the
On Mon, May 5, 2025 at 2:59 AM Nisha Moond wrote:
>
> On Fri, May 2, 2025 at 3:05 PM shveta malik wrote:
> >
> > On Fri, May 2, 2025 at 12:57 PM Nisha Moond
> > wrote:
> > >
> > >
> > > Please find the v11 patch addressing the above points and all other
> > > comments. I have also optimized the
On Mon, May 5, 2025 at 5:21 PM Sami Imseih wrote:
>
>
>> On Sat, May 3, 2025 at 1:10 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>> >
>> > On Sat, May 3, 2025 at 5:28 AM Masahiko Sawada
>> > wrote:
>> > >
>> > > > In current implementation, the leader process sends a signal to the
>> > > > a
On Tue, May 6, 2025 at 7:21 AM Sami Imseih wrote:
>
> Perhaps we should only provide a reloption, therefore only tables specified
> by the user via the reloption can be autovacuumed in parallel?
Аfter your comments (earlier in this thread) I decided to do just
that. For now we have reloption, so
On Tue, May 6, 2025 at 6:57 AM Masahiko Sawada wrote:
>
> What I roughly imagined is that we don't need to change the entire
> autovacuum scheduling, but would like autovacuum workers to decides
> whether or not to use parallel vacuum during its vacuum operation
> based on GUC parameters (having a
Hi,
I help administrate a set of reasonably large PostgreSQL* database
servers at my current place of employment. Late last week, there was a
serious failure on one of the replicas for my employer's largest
database server. I have not seen a failure like this in 10 years of
working heavily with Po
Thanks Dmitry. Right, the coordination mechanism in v4-0006 works as expected
in various tests (sorry, I misunderstood some details initially).
I also want to report a couple of minor issues found during testing (which you
may be aware of already):
1. For memory segments other the first one ('m
On Tue, May 6, 2025 at 12:26 AM Masahiko Sawada wrote:
>
> On Mon, May 5, 2025 at 3:59 AM Amit Kapila wrote:
> >
> > On Sun, May 4, 2025 at 2:33 PM Masahiko Sawada
> > wrote:
> > >
> > > While I cannot be entirely certain of my analysis, I believe the root
> > > cause might be related to the ba
Hi,
Attached is the draft of the release announcement for the 2025-05-08
release. Please review for correctness and omissions.
Please provide feedback no later than 2025-05-08 12:00 UTC.
Thanks,
Jonathan
The PostgreSQL Global Development Group has released an update to all supported
versions
On Tue, 6 May 2025 at 03:59, Bruce Momjian wrote:
>
> On Mon, May 5, 2025 at 09:42:10PM +1200, David Rowley wrote:
> > I agree that 88f55bc97 and d69d45a5a should be in their own item.
> > Likely no need to go into detail about the speed up being about
> > "EquivalenceClass lookups". I imagine so
Michael Paquier writes:
> On Thu, May 01, 2025 at 03:57:16PM -0500, Sami Imseih wrote:
>> I think what we should really allow the broader scope of expressions that
>> are allowed via prepared statements, and this will make this implementation
>> consistent between prepared vs non-prepared statemen
On Fri, 2 May 2025 14:56:56 +0200
Álvaro Herrera wrote:
> On 2025-May-02, Michael Paquier wrote:
>
> > That depends. If we conclude that tracking this information through
> > the parser based on the start and end positions in a query string
> > for a set of values is more relevant, then we woul
Tomas Vondra writes:
> My personal experience is that the growEnabled heuristics is overly
> sensitive, and probably does not trigger very often.
Yeah, it would be good to make it not quite all-or-nothing.
> But more importantly, wasn't the issue discussed in [1] about parallel
> hash joins?
I'
> On Sat, May 3, 2025 at 1:10 AM Daniil Davydov <3daniss...@gmail.com>
> wrote:
> >
> > 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 wor
On 5/6/25 01:11, Tom Lane wrote:
> The attached patch is a response to the discussion at [1], where
> it emerged that lots of rows with null join keys can send a hash
> join into too-many-batches hell, if they are on the outer side
> of the join so that they must be null-extended not just discarded
On Sat, May 3, 2025 at 1:10 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> 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 attached patch is a response to the discussion at [1], where
it emerged that lots of rows with null join keys can send a hash
join into too-many-batches hell, if they are on the outer side
of the join so that they must be null-extended not just discarded.
This isn't really surprising given that
Hi all,
A connection with only a hostaddr (no host) can't be cancelled via
PQcreateCancel(), because we'll crash in emitHostIdentityInfo(). The
problem is that the synthetic connhost entry we've created for
cancellation has an incorrect type field, which causes the following
code to make bad decis
Thomas Munro writes:
> If you run the not-yet-enabled-by-default OpenBSD CI task on master,
> ssl/001_ssltests fails in "intermediate client certificate is
> untrusted", recently uncommented by commit e0f373ee.
Yeah, I see that too. But I also see three failures in 002_scram.pl,
which presumably
Tom Lane writes:
> 2. The choice of .INI format for the config file seems a bit
> non-simpatico for Postgres. We have nothing else that uses that,
The pg_service.conf format is pretty .INI-like, it even calls itself
that in the docs:
Either service file uses an “INI file” format where the se
On Mon, May 5, 2025 at 04:12:16PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Capitalization changed, patch attached.
>
> I need to start wrapping the tarballs soon ... are you done
> with the release notes for today?
Yes, I am, thanks for asking. I was waiting for the case folding thre
Bruce Momjian writes:
> Capitalization changed, patch attached.
I need to start wrapping the tarballs soon ... are you done
with the release notes for today?
regards, tom lane
On Mon, May 5, 2025 at 3:07 PM Jonathan S. Katz wrote:
>
> Hi,
>
> Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
> The goal of this announcement is to introduce the new capabilities
> planned for PostgreSQL 18 and give users an idea of areas we'd like to
> see tested.
>
> P
05.05.2025 03:22, Jelte Fennema-Nio wrote:
[...]
I think there are a few things at play here why that did not happen in
Bruce his initial draft:
1. I personally think the requirement that Bruce uses for perf
improvements to make it into the changelog is too strict (see my
previous email for de
On Mon, May 5, 2025 at 12:20:15PM -0700, Jacob Champion wrote:
> On Thu, May 1, 2025 at 7:44 PM Bruce Momjian wrote:
> > https://momjian.us/pgsql_docs/release-18.html
>
> > +Add support for the "oauth" authentication (Jacob Champion, Daniel
> > Gustafsson, Thomas Munro)
>
> Should be e
If you run the not-yet-enabled-by-default OpenBSD CI task on master,
ssl/001_ssltests fails in "intermediate client certificate is
untrusted", recently uncommented by commit e0f373ee. I think it might
be telling us that LibreSSL's x509_store_ctx_get_current_cert() is
giving us the client certifica
On Tue, Apr 08, 2025 at 01:07:09PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I do think it's worth considering going back to copying
>> pg_largobject_metadata's files for upgrades from v16 and newer.
>
> (If we do this) I don't see why we'd need to stop at v16. I'm
> envisioning that we
On Thu, May 1, 2025 at 7:44 PM Bruce Momjian wrote:
> https://momjian.us/pgsql_docs/release-18.html
> +Add support for the "oauth" authentication (Jacob Champion, Daniel
> Gustafsson, Thomas Munro)
Should be either 'support for "oauth" authentication' or 'support for
the "oauth" authent
Hi,
Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
The goal of this announcement is to introduce the new capabilities
planned for PostgreSQL 18 and give users an idea of areas we'd like to
see tested.
Please check for accuracy and if there are glaring omissions (happy
On Mon, May 5, 2025 at 02:09:26PM +, Bertrand Drouvot wrote:
> A.
>
> "Per-backend I/O statistics can be cleared via pg_stat_reset_backend_stats()"
>
> and
>
> "Per-backend WAL statistics can be cleared via pg_stat_reset_backend_stats()"
>
> for consitency.
>
> Or:
I went with the A opti
On Mon, May 5, 2025 at 3:59 AM Amit Kapila wrote:
>
> On Sun, May 4, 2025 at 2:33 PM Masahiko Sawada wrote:
> >
> > While I cannot be entirely certain of my analysis, I believe the root
> > cause might be related to the backward movement of the confirmed_flush
> > LSN. The following scenario seem
On Mon, May 5, 2025 at 10:14:22PM +1200, David Rowley wrote:
> On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> > You can see the most current HTML-built version here:
> >
> > https://momjian.us/pgsql_docs/release-18.html
>
> Thanks for working on these.
>
> For "Improve the performa
05.05.2025 17:05, Bertrand Drouvot пишет:
> Hi,
>
> On Mon, May 05, 2025 at 02:15:15PM +0300, Yura Sokolov wrote:
>> Interestingly, our colleague stepped into same problem recently [1] . It
>> happened because he attempted to make overcomplex timeout (SIGALARM) handler.
>>
>> But his solution was
On Mon, May 5, 2025 at 09:42:10PM +1200, David Rowley wrote:
> On Fri, 2 May 2025 at 16:01, Amit Langote wrote:
> > +Allow partitions to be pruned earlier and quicker, and skipped in
> > more places (Amit Langote, Ashutosh Bapat, Yuya Watari, David Rowley)
> >
> > Alternatively, 2 and 3 can be co
On Monday, May 5, 2025, Robert Haas wrote:
> On Thu, May 1, 2025 at 2:22 PM Robert Haas wrote:
> > > The other approach would be to do what we do for the role options and
> just specify everything explicitly in the dump. The GUC is only a default
> specifier so let's not leave room for defaults
On Sun, May 4, 2025 at 8:54 AM Nikhil Kumar Veldanda
wrote:
> I agree. Each compression algorithm can decide its own metadata size
> overhead. Callbacks can provide this information as well rather than
> storing in fixed length bytes(3 bytes). The revised patch introduces a
> "toast_cmpid_meta_siz
>On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote:
>> I have committd the first draft of the PG 18 release notes.
>I don't think pg_buffercache_numa does exist.
Please ignore
Regards
Daniel
On Fri, May 2, 2025 at 9:54 PM Fujii Masao wrote:
> Thanks for the review and testing! I've fixed the issue you pointed out.
> Updated patch attached.
Thanks for addressing this. However, I believe this commit may need to
take note of the following comment from elog.h:
* Note: if a local variab
On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote:
> I have committd the first draft of the PG 18 release notes.
I don't think pg_buffercache_numa does exist.
Regards
Daniel
Laurenz Albe writes:
> On Sat, 2025-05-03 at 22:47 -0700, Tanin Na Nakorn wrote:
>> Here's the patch (against the latest master) that will make pg_dump support
>> "on conflict do update" .
>>
>> There are 3 caveats:
>>
>> 1. The "on conflict do update" would apply to every table. In my opinion,
Hi,
On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote:
> I have committd the first draft of the PG 18 release notes.
Thanks for working on this!
> You can see the most current HTML-built version here:
>
> https://momjian.us/pgsql_docs/release-18.html
I have one comment rela
Hi,
On Mon, May 05, 2025 at 02:15:15PM +0300, Yura Sokolov wrote:
> Interestingly, our colleague stepped into same problem recently [1] . It
> happened because he attempted to make overcomplex timeout (SIGALARM) handler.
>
> But his solution was a bit different [2].
>
> [1] https://postgr.es/m/0
Andrei Lepikhov писал(а) 2025-05-05 14:38:
On 4/29/25 19:25, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-04-29 16:52:
But it seems, base_path can't be NULL
Correct. Fixed.
Also we check base_path for required_outer and require_parallel_safe,
but if cheapest path for pathkeys is N
Hi,
On Mon, May 05, 2025 at 12:15:39PM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> Thanks for the report and the patch!
>
> On Mon, 5 May 2025 at 10:53, Bertrand Drouvot
> wrote:
> >
> > The proposed fix attached is done in ConditionVariableTimedSleep() as this
> > is the
> > place that introduc
Here's a rebase.
bg_buffer_sync_clarity.patch
Description: Binary data
Hi hackers,
While reviewing the import/export statistics, I noticed that relation
locking are handled via relation_open() and relation_close() in
stats_lock_check_privileges(), and no calls to other lock-manager
routines are actually used there. As a result, the inclusion of the
lock-manager
Hi, tks for working on this. I had a chance to look at this while
googling BgBufferSync
function.
>
> I also think tha reusable_buffers keep track of the number of reusable
> buffers. BgBufferSync() calls SyncOneBuffer() with skip_recently_used
> = true. In that case, if SyncOneBuffer() finds th
Hi,
On Sat, 2025-05-03 at 16:54 +0200, Christoph Berg wrote:
> The package split between libpq5 and libpq-oauth in Debian has already
> been accepted into the experimental branch.
RPMs will ship postgresql18-libs and postgresql18-libs-oauth. The latter
depends on the former for sure.
Regards,
-
On Thu, May 1, 2025 at 2:22 PM Robert Haas wrote:
> > The other approach would be to do what we do for the role options and just
> > specify everything explicitly in the dump. The GUC is only a default
> > specifier so let's not leave room for defaults in the dump file.
>
> +1 for considering t
On Thu, May 1, 2025 at 10:27 AM Fujii Masao wrote:
>
> >
> > Additionally, shall we try to reproduce this case for parallel apply
> > workers?
>
> I noticed this issue while reading the code, so I haven't actually reproduced
> it.
> Are you saying it's not possible to reproduce this in practice?
On 5/5/25 13:38, Andrei Lepikhov wrote:
Let's check next version of the patch in the attachment.
Oops, I forgot some tails - see this new version.
--
regards, Andrei LepikhovFrom 7b312c38bf9f2370c970dc0058d38610cb1ae6c6 Mon Sep 17 00:00:00 2001
From: "Andrei V. Lepikhov"
Date: Thu, 24 Apr 2025
On 4/29/25 19:25, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-04-29 16:52:
But it seems, base_path can't be NULL
Correct. Fixed.
Also we check base_path for required_outer and require_parallel_safe,
but if cheapest path for pathkeys is NULL, these checks are not
performed.
Than
05.05.2025 10:52, Bertrand Drouvot пишет:
> Hi hackers,
>
> While working on wait event related stuff I observed a failed assertion:
>
> "
> TRAP: failed Assert("node->next == 0 && node->prev == 0"), File:
> "../../../../src/include/storage/proclist.h", Line: 91
> "
>
> during pg_regress/databa
On Sun, May 4, 2025 at 2:33 PM Masahiko Sawada wrote:
>
> While I cannot be entirely certain of my analysis, I believe the root
> cause might be related to the backward movement of the confirmed_flush
> LSN. The following scenario seems possible:
>
> 1. The walsender enables the two_phase and sets
On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> You can see the most current HTML-built version here:
>
> https://momjian.us/pgsql_docs/release-18.html
Thanks for working on these.
For "Improve the performance of hash joins (David Rowley)", 0f5738202
did the same thing for GROUP BY a
On Fri, May 2, 2025 at 3:05 PM shveta malik wrote:
>
> On Fri, May 2, 2025 at 12:57 PM Nisha Moond wrote:
> >
> >
> > Please find the v11 patch addressing the above points and all other
> > comments. I have also optimized the test by reducing the number of
> > subscriptions and slots.
> >
>
> Tha
On Fri, 2 May 2025 at 16:01, Amit Langote wrote:
> +Allow partitions to be pruned earlier and quicker, and skipped in
> more places (Amit Langote, Ashutosh Bapat, Yuya Watari, David Rowley)
>
> Alternatively, 2 and 3 can be combined as:
> 2. Speed up partition planning by improving EquivalenceCla
Hi,
Thanks for the report and the patch!
On Mon, 5 May 2025 at 10:53, Bertrand Drouvot
wrote:
>
> The proposed fix attached is done in ConditionVariableTimedSleep() as this is
> the
> place that introduces the race condition. It re-assigns cv_sleep_target to cv
> and then ensures that cv_sleep_
Hi hackers,
An inconsistency was observed when using logical replication on partitioned
tables with the option `publish_via_partition_root = true`: if REPLICA IDENTITY
FULL is set only on the parent table, but not on all partitions, logical
decoding emits UPDATE and DELETE messages with tag 'O' (o
Hi hackers,
While working on wait event related stuff I observed a failed assertion:
"
TRAP: failed Assert("node->next == 0 && node->prev == 0"), File:
"../../../../src/include/storage/proclist.h", Line: 91
"
during pg_regress/database.
To reproduce, add an ereport(LOG,..) or CHECK_FOR_INTERRU
On Sat, 2025-05-03 at 22:47 -0700, Tanin Na Nakorn wrote:
> Here's the patch (against the latest master) that will make pg_dump support
> "on conflict do update" .
>
> I've used this patch on v16 for our company's CI (on Github Actions), and it
> works perfectly fine.
>
> Users would be able to
21.03.2025 19:33, Andres Freund пишет:
> Hi,
>
> On 2025-03-21 14:35:16 +0300, Yura Sokolov wrote:
>> From 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001
>> From: Yura Sokolov
>> Date: Mon, 3 Feb 2025 11:58:33 +0300
>> Subject: [PATCH v2] sinvaladt.c: use atomic operations on m
64 matches
Mail list logo
