On 2025-Apr-30, Peter Eisentraut wrote:
> On 29.04.25 23:54, Nathan Bossart wrote:
> > Fair point. We seem to be pivoting towards long options, anyway. If
> > there's support for this, I could go through all the client and server
> > application docs to ensure they match this style.
>
> However
Just rebase
--
regards
Yura Sokolov aka funny-falconFrom 4ea25d6feb655a072d1e9f40a547dc6aeab762ac Mon Sep 17 00:00:00 2001
From: Yura Sokolov
Date: Sun, 19 Jan 2025 17:40:28 +0300
Subject: [PATCH v6] Lock-free XLog Reservation using lock-free hash-table
Removed PrevBytePos to eliminate lock con
On Wed, Apr 30, 2025 at 5:15 AM Peter Eisentraut wrote:
>
> On 28.04.25 18:56, Álvaro Herrera wrote:
> > On 2025-Apr-23, Nathan Bossart wrote:
> >
> >> On Mon, Mar 24, 2025 at 11:37:20AM +0100, Álvaro Herrera wrote:
> >
> >>> I'd add a note about these two things to the open items page, and wait
>
On Tue, Apr 29, 2025 at 6:57 PM Amit Kapila wrote:
>
> On Tue, Apr 29, 2025 at 3:01 AM Masahiko Sawada
> wrote:
> >
> > Your fix looks good to me. Is it worth considering putting an
> > assertion to verify if new two_phase_at is equal to or greater than
> > confirmed_lsn (or at least it doesn't g
Hi,
On 2025-04-28 08:55, Hannu Krosing wrote:
Have you also checked out
https://github.com/postgrespro/pg_query_state which logs running query
plan AND collected counts and timings as a response to a signal?
Yes. For example, see the discussion:
https://www.postgresql.org/message-id/d68c3ae316
On 29.04.25 23:54, Nathan Bossart wrote:
On Tue, Apr 29, 2025 at 11:45:11PM +0200, Álvaro Herrera wrote:
I think the concept here is that all short options go first in
alphabetical order, then the long options in their own alphabetical
order, and if one option has both, then the short option tak
Hi Nikita, wenhui,
On Fri, Apr 25, 2025 at 11:16 PM Nikita Malakhov wrote:
>
> Hi!
>
> I agree it is a good idea to shift the table list. Although vacuuming larger
> tables first
> is a questionable approach because smaller ones could wait a long time to be
> vacuumed.
> It looks like the most
On 4/30/25 13:22, Alexander Korotkov wrote:
Thank you, Andrei. I've put it all together.
0001 Fixes material bugs in ChangeVarNodes_walker() including regression test
0002 Puts back comments which got accidentally removed
0003 Refactors ChangeVarNodesExtended() with custom user-defined callback
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> On 2025-Apr-28, Tom Lane wrote:
>> +BlockNumber numNonLeafPages;/* # of index pages that are not leafs
>> */
> I find the use of "leafs" as plural for "leaf" a bit strange ...
> We already have uses of that word, but I wonder if they don't mostly
Hi,
we would like to propose the removal of the Instruction
Synchronization Barrier (isb) for aarch64 architectures. Based on our
testing on Graviton instances (m7g.16xlarge), we can see on average
over multiple iterations up to 12% better performance using PGBench
select-only and up to 9% with Sys
On 2025-Apr-28, Tom Lane wrote:
> @@ -135,6 +141,7 @@ typedef struct
> double numIndexTuples; /* number of leaf tuples visited */
> double spc_random_page_cost; /* relevant random_page_cost
> value */
> double num_sa_scans; /* # indexscans from Sca
> On 30 Apr 2025, at 12:14, Peter Eisentraut wrote:
>
> On 29.04.25 15:13, Rahila Syed wrote:
>> Please find attached a patch with some comments and documentation changes.
>> Additionaly, added a missing '\0' termination to "Remaining Totals" string.
>> I think this became necessary after we repl
On Fri, Apr 25, 2025 at 10:02:49PM +0800, Junwang Zhao wrote:
> After watching Robert's talk[1] on autovacuum and participating in the related
> workshop yesterday, it appears that people are inclined to use prioritization
> to address the issues highlighted in Robert's presentation. Here I list tw
Hi, all
While working on [1], I found outdated comments in IndexInfo.
The attached patch corrects them.
[1]
https://www.postgresql.org/message-id/2A40921D-83AB-411E-ADA6-7E509A46F1E4%40logansw.com
--
Regrads,
Japin Li
>From 7c01644860a32ca9ab93367c2f8e34047c9d703f Mon Sep 17 00:00:00 2001
Fr
On Wed, 30 Apr 2025 at 19:13, Fujii Masao wrote:
> This commit seems to have caused an indent-check failure on the buildfarm
> member koel.
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=koel&dt=2025-04-30%2002%3A19%3A00
Thanks. Fixed.
David
On Wed, Apr 30, 2025 at 10:52:51AM +0500, Andrey Borodin wrote:
> Did you consider custom resource manager to WAL-log injection
> points? This way we do not need to flush them explicitly, they
> always will be persistent.
WAL-logging would not work in the case I've faced, because we need a
point m
On Wed, Apr 30, 2025 at 04:46:37PM +0200, Álvaro Herrera wrote:
> On 2025-Apr-30, Peter Eisentraut wrote:
>> On 29.04.25 23:54, Nathan Bossart wrote:
>> > Fair point. We seem to be pivoting towards long options, anyway. If
>> > there's support for this, I could go through all the client and serve
On Thu, Apr 24, 2025 at 03:25:55PM +0200, Christoph Berg wrote:
> Re: Nathan Bossart
>> Here is what I have staged for commit. I'll aim to commit these patches
>> sometime next week to give time for additional feedback.
>
> I confirm my PG13 test table gets analyzed now with the patch.
Committed
Hello Tom,
Sorry if I've chosen the wrong thread, but starting from 0313c5dc6,
the following script:
CREATE TYPE aggtype AS (a int, b text);
CREATE FUNCTION aggfns_trans(aggtype[], integer, text) RETURNS aggtype[] LANGUAGE sql AS 'SELECT
array_append($1,ROW($2,$3)::aggtype)';
CREATE AGGREGATE a
Hi,
After a bit more private back and forth with Alexander I have found the issue
- and it's pretty stupid:
pgaio_io_wait_for_free() does what it says on the tin. For that, after a bunch
of other things, finds the oldest in-flight IO and waits for it.
PgAioHandle *ioh = dclist_he
On Tue, Apr 6, 2021 at 12:45 AM Fujii Masao wrote:
> Add function to log the memory contexts of specified backend process.
Hi,
I think this might need a recursion guard. I tried this:
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index dc4c600922d..b219a934034 100644
--
> Yes, it is masking the problem, but maybe a better way to think about it is
> that it is delaying the
> performance impact, allowing more time for a manual intervention of the
> problematic table(s).
I question how the user will gauge the success of setting the strategy
to "random"? They may m
I forgot to add the proper tests to the Normalize cursor utility statements.
Reattaching v2.
I also want to add that the decision to not normalize the cursor name in
the FETCH command is because it would not make sense to combine
FETCH commands for various cursors into the same entry.
Regards,
-
On Wed, Apr 30, 2025 at 10:07 AM Junwang Zhao wrote:
> I ended up with adding a guc configuration that may support different
> vacuum
> strategies.
+1 to this: it's a good solution to a tricky problem. I would be a -1 if
this were not a GUC.
Yes, it is masking the problem, but maybe a better w
On Wed, Apr 30, 2025 at 5:55 AM Daniel Gustafsson wrote:
> > To keep things moving: I assume this is unacceptable. So v10 redirects
> > every access to a PGconn struct member through a shim, similarly to
> > how conn->errorMessage was translated in v9. This adds plenty of new
> > boilerplate, but
> On 30 Apr 2025, at 19:59, Jacob Champion
> wrote:
> On Wed, Apr 30, 2025 at 5:55 AM Daniel Gustafsson wrote:
>> Nitpick, but it won't be .so everywhere. Would this be clearar if spelled
>> out
>> with something like "do not rely on libpq-int.h when building libpq-oauth as
>> dynamic shared
On Wed, Apr 30, 2025 at 1:56 PM Sami Imseih wrote:
>
> > Yes, it is masking the problem, but maybe a better way to think about it is
> > that it is delaying the
> > performance impact, allowing more time for a manual intervention of the
> > problematic table(s).
>
> I question how the user will
On Wed, 30 Apr 2025 at 17:41, Amit Kapila wrote:
>
> On Wed, Apr 30, 2025 at 11:22 AM Tom Lane wrote:
> >
> > Xuneng Zhou pointed out on Discord that the test case added by
> > 7c99dc587 has caused repeated failures in CI --- though oddly,
> > it's not failed in the buildfarm so far as I can find
> - Spinning. Running repeatedly on the same table but not accomplishing
> anything useful.
> But more importantly, IMHO it masks the problems instead of
> solving them more directly, and it could mask future problems, too
To add more to Nathan's comment about masking future problems,
this will n
On Wed, Apr 30, 2025 at 09:29:59AM +0900, Michael Paquier wrote:
> On Tue, Apr 29, 2025 at 03:55:08PM -0500, Nathan Bossart wrote:
>> Assuming we want this patch, should we apply it to v18? It's arguably an
>> oversight in the pg_dump --sequence-data commit, and pg_dumpall will just
>> pass the op
On Sat, Apr 26, 2025 at 5:07 PM Tomas Vondra wrote:
> > Just for the record, it sounds quite unsafe to me too. I could
> > credit it being all right to examine the process' MemoryContext data
> > structures, but calling dsa_create() from CFI seems really insane.
> > Way too many moving parts ther
> On 30 Apr 2025, at 22:17, Robert Haas wrote:
> I kind of doubt whether that's the only problem here, but it's *a* problem.
This is indeed exposing a pre-existing issue, which was reported in [0] and a
patch fixing it has been submitted. I have been testing and reworking the
patch slightly but
necro-ing an old thread ...
Robert Haas writes:
> [ v4-0002-Add-new-GUC-createrole_self_grant.patch ]
I confess to not having paid close enough attention when
these patches went in, or I would have complained about
createrole_self_grant. It changes the user-visible behavior
of SQL commands, spe
Hi hackers,
I recently looked into a workload that makes heavy use of explicit cursors,
and I found that pg_stat_statements can become a bottleneck. The
application in question declares hundreds of cursors, and for each one,
performs many FETCH and MOVE operations with varying fetch sizes.
As a r
On 2025/04/30 10:41, David Rowley wrote:
On Wed, 30 Apr 2025 at 13:25, Junwang Zhao wrote:
Found a trivial typo in multixact.c, after searching the code base
there is another such typo in jsonfuncs.c.
Thanks. Pushed.
This commit seems to have caused an indent-check failure on the buildfa
On 28.04.25 18:56, Álvaro Herrera wrote:
On 2025-Apr-23, Nathan Bossart wrote:
On Mon, Mar 24, 2025 at 11:37:20AM +0100, Álvaro Herrera wrote:
I'd add a note about these two things to the open items page, and wait
to see if we get some of these limitations fixed, so that if we don't,
we reme
On Sun, Apr 27, 2025 at 2:02 PM Alexander Korotkov wrote:
>
> On Fri, Apr 11, 2025 at 5:46 PM Andrei Lepikhov wrote:
> > On 4/10/25 14:39, Andrei Lepikhov wrote:
> > > On 4/10/25 13:36, Alexander Korotkov wrote:
> > >> On Wed, Apr 9, 2025 at 10:39 AM Andrei Lepikhov
> > >> wrote:
> > >>> It seem
On Tue, Apr 22, 2025 at 5:00 PM Peter Smith wrote:
>
> Hi Ajin,
>
> Some review comments for patch v17-0001
>
> ==
> Commit message
>
> 1.
> Additionally, transactions containing WAL records (INTERNAL_SNAPSHOT,
> COMMAND_ID, or INVALIDATION) that modify the historical snapshot
> constructed du
> On 29 Apr 2025, at 02:10, Jacob Champion
> wrote:
>
> On Wed, Apr 23, 2025 at 10:46 AM Jacob Champion
> wrote:
>> Are there any readers who feel like an internal ABI version for
>> `struct pg_conn`, bumped during breaking backports, would be
>> acceptable? (More definitively: are there any re
Hi,
In the functions addItemPointersToLeafTuple and buildFreshLeafTuple
(in gininsert.c), the result of ginCompressPostingList()
is passed to GinFormTuple without checking whether
ginCompressPostingList() successfully packed all items.
These GinFormTuple calls consistently fail because the resulti
On 29.04.25 15:13, Rahila Syed wrote:
Please find attached a patch with some comments and documentation changes.
Additionaly, added a missing '\0' termination to "Remaining Totals" string.
I think this became necessary after we replaced dsa_allocate0()
with dsa_allocate() is the latest version.
On Wed, Apr 30, 2025 at 11:22 AM Tom Lane wrote:
>
> Xuneng Zhou pointed out on Discord that the test case added by
> 7c99dc587 has caused repeated failures in CI --- though oddly,
> it's not failed in the buildfarm so far as I can find. The
> failures look like
>
> timed out waiting for match: (
On 4/18/25 03:03, Vinod Sridharan wrote:
> Hello,
> As part of testing this change I believe I found a scenario where the
> parallel build seems to trigger OOMs for larger indexes. Specifically,
> the calls for ginEntryInsert seem to leak memory into
> TopTransactionContext and OOM/crash the out
On 2025/04/29 21:21, Amit Kapila wrote:
On Mon, Apr 28, 2025 at 2:37 PM Fujii Masao wrote:
On 2025/04/26 3:03, Masahiko Sawada wrote:
I agree with these changes.
I think that while the changes for (2) should be for v19, the changes
for (1) might be treated as a bug fix?
Agreed. I've spli
Hi Sami,
On Thu, May 1, 2025 at 1:56 AM Sami Imseih wrote:
>
> > Yes, it is masking the problem, but maybe a better way to think about it is
> > that it is delaying the
> > performance impact, allowing more time for a manual intervention of the
> > problematic table(s).
>
> I question how the u
On Wed, Apr 30, 2025 at 02:43:41PM -0500, Sami Imseih wrote:
> I also want to add that the decision to not normalize the cursor name in
> the FETCH command is because it would not make sense to combine
> FETCH commands for various cursors into the same entry.
- calls | rows |
On Thu, May 1, 2025 at 8:12 AM David Rowley wrote:
>
> On Thu, 1 May 2025 at 03:29, Nathan Bossart wrote:
> > That being said, I am -1 for this proposal. Autovacuum parameters and
> > scheduling are already quite complicated, and making it nondeterministic
> > would add an additional layer of co
Does it make sense to load "shared_preload_libraries" during binary
upgrade mode?
An extension might unintentionally interfere with pg_upgrade, for
example, by connecting to the 'postgres' database, which can cause the
upgrade to fail as the restore needs to drop that database. While it's
true tha
On Thu, 1 May 2025 at 17:35, Junwang Zhao wrote:
>
> On Thu, May 1, 2025 at 8:12 AM David Rowley wrote:
> > It sounds like the aim is to fix the problem with autovacuum vacuuming
> > the same table over and over and being unable to remove enough dead
> > tuples due to something holding back the o
Hi,
It seems to me that, in doc/src/sgml/ref/pgupgrade.sgml, this phrase:
"Because not all statistics are not transferred"
should be:
"Because not all statistics are transferred"
Thanks,
Erik
On Thu, May 1, 2025 at 12:49 AM Japin Li wrote:
> While working on [1], I found outdated comments in IndexInfo.
> The attached patch corrects them.
Nice catch. LGTM.
Thanks
Richard
62d712ec added the ability to squash constants from an IN LIST
for queryId computation purposes. This means that a similar
queryId will be generated for the same queries that only
different on the number of values in the IN-LIST.
The patch lacks the ability to apply this optimization to values
pas
On Wed, Apr 30, 2025 at 4:29 PM Daniel Gustafsson
wrote:
> This is indeed exposing a pre-existing issue, which was reported in [0] and a
> patch fixing it has been submitted. I have been testing and reworking the
> patch slightly but due to $life and $work events have yet to have time to push
> i
On Wed, Apr 30, 2025 at 5:24 PM Daniel Gustafsson wrote:
> Attached is a current v4 with a few small tweaks.
Sorry to turn up late here, but I strongly disagree with the notion
that this is a bug in the DSM or DSA code. It seems to me that it is
the caller's responsibility to provide a valid reso
On Wed, Apr 30, 2025 at 2:38 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Tue, Apr 29, 2025 at 6:57 PM Amit Kapila wrote:
> >
> > On Tue, Apr 29, 2025 at 3:01 AM Masahiko Sawada
> > wrote:
> > >
> > > Your fix looks good to me. Is it worth considering putting an
> > > assertion to verify if new two_phas
On Thu, 1 May 2025 at 03:29, Nathan Bossart wrote:
> That being said, I am -1 for this proposal. Autovacuum parameters and
> scheduling are already quite complicated, and making it nondeterministic
> would add an additional layer of complexity (and may introduce its own
> problems). But more imp
Alexander Lakhin writes:
> Sorry if I've chosen the wrong thread, but starting from 0313c5dc6,
> the following script:
> CREATE TYPE aggtype AS (a int, b text);
> CREATE FUNCTION aggfns_trans(aggtype[], integer, text) RETURNS aggtype[]
> LANGUAGE sql AS 'SELECT
> array_append($1,ROW($2,$3)::aggt
On Wed, Apr 30, 2025 at 04:52:06PM -0500, Sami Imseih wrote:
> 62d712ec added the ability to squash constants from an IN LIST
> for queryId computation purposes. This means that a similar
> queryId will be generated for the same queries that only
> different on the number of values in the IN-LIST.
Peter,
moving the conversation here from "pgsql: Improve nbtree skip scan
primitive scan scheduling" thread on -committers. Attached is another
regression test for your consideration, which gives rise to the following
assertion:
TRAP: failed Assert("numSkipArrayKeys == 0"), File: "nbtpreprocessk
On Wed, Apr 30, 2025 at 9:12 PM Mark Dilger
wrote:
> TRAP: failed Assert("numSkipArrayKeys == 0"), File: "nbtpreprocesskeys.c",
> Line: 1859, PID: 7210
> 0 postgres0x0001032f30e0
> ExceptionalCondition + 108
> 1 postgres0x000102
Alexander Lakhin writes:
> Sorry if I've chosen the wrong thread, but starting from 0313c5dc6,
> the following script:
> ...
> crashes the server for me like this:
> corrupted size vs. prev_size while consolidating
Yup, duplicated here. Thanks for the report!
regards, to
> On 11 Apr 2025, at 21:08, Rahila Syed wrote:
>
> Hi Daniel,
>
> Thank you for your review and code improvements.
>
> Please find below some observations.
>
> 1. dsm_unpin_mapping(dsm_segment *seg)
> + if (CurrentResourceOwner &&
> IsResourceOwnerReleasing(CurrentResourceOwner))
> +
Hi all,
During index bulk-deletion in lazy vacuum, we currently check the
deletability of each index tuple individually using the
vac_tid_reaped() function. The attached proof-of-concept patches
propose batching multiple TID lookups for deletability checks to
reduce overhead. This optimization aim
On Wed, Mar 12, 2025 at 10:52:57AM +, Bertrand Drouvot wrote:
> Note that it does not add extra explanation to "cost-based delay". If we feel
> the
> need we could add a link to " linkend="runtime-config-resource-vacuum-cost"/>"
> like it has been done for delay_time in bb8dff9995f.
Sorry for
On Wed, Apr 30, 2025 at 1:29 PM Tom Lane wrote:
> But don't we need to add
createrole_self_grant to the set of GUCs that pg_dump[all]
> resets in the emitted SQL?
>
>
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
On Wed, Apr 30, 2025 at 06:03:49PM -0400, Robert Haas wrote:
> Sorry to turn up late here, but I strongly disagree with the notion
> that this is a bug in the DSM or DSA code. It seems to me that it is
> the caller's responsibility to provide a valid resource owner, not the
> job of the called code
Hi,
On Wed, Apr 16, 2025 at 4:05 AM Maxim Orlov wrote:
>
> Hi!
>
> The VACUUM command can be executed with the parallel option. As documentation
> states, it will perform index vacuum and index cleanup phases of VACUUM in
> parallel using integer background workers. But such an interesting feat
67 matches
Mail list logo
