On Mon, Apr 28, 2025 at 7:12 AM Michael Paquier wrote:
> I've reproduced your original report with clang-tidy on my end,
> removed the include that was not required in wait_event.h, fixed one
> comment, cross-checked that the result actually works, and applied the
> result. Thanks for the report!
On Mon, Jun 30, 2025 at 01:36:12PM +, Bertrand Drouvot wrote:
> It could also be useful to observe the engine/backends behavior over time and
> help answer questions like:
>
> * Is the engine’s wait pattern the same over time?
> * Is application’s "A" wait pattern the same over time?
> * I obs
On Fri, Jul 4, 2025 at 10:11 PM Tom Lane wrote:
>
> Andres Freund writes:
> >> +/* restore so that extensions can include the C++ APIs */
> >> +#undef U_SHOW_CPLUSPLUS_API
>
> > Does the #undef U_SHOW_CPLUSPLUS_API thing actually work, given that ucol.h
> > presumably won't be included again due
On Mon, Jul 7, 2025 at 9:47 AM Dilip Kumar wrote:
>
> On Sun, Jul 6, 2025 at 11:57 PM Tom Lane wrote:
> >
> > [ resurrecting an old thread ]
> >
> > Amit Kapila writes:
> > > +bool
> > > +check_max_slot_wal_keep_size(int *newval, void **extra, GucSource source)
> > > +{
> > > + if (IsBinaryU
Attached is the v16 patch.
In this patch I have changed row_is_in_frame() API from:
static int row_is_in_frame(WindowAggState *winstate, int64 pos,
TupleTableSlot *slot);
to:
static int row_is_in_frame(WindowObject winobj, int64
Hello Michail,
07.07.2025 03:18, Michael Paquier wrote:
I'm failing to reproduce it, unfortunately. It looks like just a
timing issue with the reports, so the best option I can think of here
would be to switch the test to do a wait until the stats have been
generated, leading to the attached.
On Fri, Jul 4, 2025 at 7:42 PM Ashutosh Bapat
wrote:
>
> On Fri, Jul 4, 2025 at 9:23 AM Amit Kapila wrote:
> > > >
> > >
> > > How about this:
> > > We change the following sentence in the third paragraph
> > > To confirm that the standby server is indeed ready for failover > > addition> so that
On Sun, Jul 6, 2025 at 11:57 PM Tom Lane wrote:
>
> [ resurrecting an old thread ]
>
> Amit Kapila writes:
> > +bool
> > +check_max_slot_wal_keep_size(int *newval, void **extra, GucSource source)
> > +{
> > + if (IsBinaryUpgrade && *newval != -1)
> > + {
> > + GUC_check_errdet
On Sun, Jul 06, 2025 at 11:07:11AM -0700, Noah Misch wrote:
> A challenge is that the number of files in pg_twophase can exceed
> max_prepared_transactions if we've not yet reached consistency. That happens
> with a sequence like this:
>
> - exactly max_prepared_transactions files are in pg_twoph
Dear Sawada-san,
> What does each duration mean in these results? Can we interpret the
> test case of max_conflict_retention_duration=120s that when 7 clients
> and 15 clients are working on the publisher and the subscriber
> respectively, the TPS on the subscriber was about one fourth (17835.3
>
Hi Hackers,
Here are some documentation patches about inlining SQL-language functions. Postgres has been able to
inline both scalar and set-returning functions since the 9.x days (as long as they are LANGUAGE SQL
and meet a bunch of other conditions). But this was never documented outside of a
On Sun, Jul 6, 2025 at 10:51 PM Masahiko Sawada wrote:
>
> On Sun, Jul 6, 2025 at 8:03 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear hackers,
> >
> > As a confirmation purpose, I did performance testing with four
> > workloads we did before.
>
> Thank you for doing the performance tests!
>
On Mon, Jul 07, 2025 at 11:06:06AM +0900, Michael Paquier wrote:
> On Sun, Jul 06, 2025 at 09:13:19AM -0700, Noah Misch wrote:
> > This new PQservice() function from commit 4b99fed75 came up in the annual
> > exports.txt diff. The standard in libpq has been to not clutter the API
> > with
> > new
hi.
rebased only.
From 3ff7dd0fd260a6b3a35f8652f0840ab96bc68c70 Mon Sep 17 00:00:00 2001
From: jian he
Date: Mon, 7 Jul 2025 10:07:25 +0800
Subject: [PATCH v2 1/1] allow change generated expression while check
constraint on it
currently, if we have check constraints over virtual generated column
On Sun, Jul 6, 2025 at 10:51 PM Masahiko Sawada wrote:
>
> On Fri, Jul 4, 2025 at 8:18 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wed, Jul 2, 2025 at 3:28 PM Hou, Zhijie wrote:
> > > Kindly use the latest patch set for performance testing.
> >
> > During testing, we observed a limitation in casc
Hi
> Thanks, LGTM.
I think it's possible to register to https://commitfest.postgresql.org/54,
https://commitfest.postgresql.org/53 will closed soon
Thanks
On Fri, Jul 4, 2025 at 10:50 AM Japin Li wrote:
> On Thu, 03 Jul 2025 at 12:59, John H wrote:
> > Hi,
> >
> > On Wed, Jul 2, 2025 at 6:40
On Sun, Jul 06, 2025 at 09:13:19AM -0700, Noah Misch wrote:
> This new PQservice() function from commit 4b99fed75 came up in the annual
> exports.txt diff. The standard in libpq has been to not clutter the API with
> new functions that simply retrieve one PQconninfoOption value. PQconninfo()
> pr
nbtree's _bt_first function uses arrays on the stack to store the scan
keys that will be used for initial positioning purposes. We could use
dynamic allocation here instead, but experience has shown that that
would cause performance issues -- particularly during nestloop joins
with an inner index s
On Fri, Jul 04, 2025 at 12:44:56AM -0400, Tom Lane wrote:
>> The last batch of libxml deprecation warning fixes we have done was
>> last year in [1], so the one we have here is new. It seems to me that
>> it would not hurt to just backpatch that all the way down rather than
>> waiting. Comments a
On Fri, Jul 4, 2025 at 4:03 PM Japin Li wrote:
...
> When trying vic, I received the following error:
>
> TRAP: failed Assert("TransactionIdIsNormal(xmax)"), File:
> "/data/Codes/pg/master/build/../src/backend/access/heap/heapam.c", Line:
> 7373, PID: 1719347
> postgres: japin postgres [local]
On Sun, Jul 06, 2025 at 12:00:00PM +0300, Alexander Lakhin wrote:
> This test case is rather new, it was added by f4694e0f3 (from 2025-03-05).
Thanks for the report.
> I could reproduce this failure within 20 test runs with the following
> modification:
> --- a/src/backend/postmaster/walsummarize
On Sat, Jul 5, 2025 at 7:16 AM Noah Misch wrote:
>
> On Mon, Mar 31, 2025 at 09:18:30PM +0300, Alexander Korotkov wrote:
> > I'm going to push the first patch ("nowalbuf") if no objections.
>
> I completed a post-commit review of this patch. I think the patch is correct.
Great. I'm glad to hear
On Sat, Feb 3, 2024 at 8:54 AM Hannu Krosing wrote:
>
> My justification for adding pl/pgsql tests as part of the immediately
> available tests
> is that pl/pgsql itself is always enabled, so having a no-effort way to test
> its
> performance benefits would be really helpful.
> We also should ha
On 2025-Jul-06, Arseniy Mukhin wrote:
> Sorry, forget to run a full test run with the new patch version. Some
> tests were unhappy with the new unknown support function. Here the new
> version with the fix.
Hello, I think this patch is probably a good idea. I don't think it
makes sense to introd
[ resurrecting an old thread ]
Amit Kapila writes:
> +bool
> +check_max_slot_wal_keep_size(int *newval, void **extra, GucSource source)
> +{
> + if (IsBinaryUpgrade && *newval != -1)
> + {
> + GUC_check_errdetail("\"%s\" must be set to -1 during binary
> upgrade mode.",
> +
Here is the latest patch with documentation only for the utility
itself. Old general discussion moved to PostgreSQL Wiki with link to
it in "See Also " section
Also added a flag to select number of direct values to show
On Sun, Nov 3, 2024 at 11:19 PM Tom Lane wrote:
>
> Hannu Krosing writes:
>
On Fri, Jun 20, 2025 at 09:02:00AM +0900, Michael Paquier wrote:
> On Fri, Jun 06, 2025 at 03:34:13PM -0700, Noah Misch wrote:
> > Shared memory should (not "must") omit a GXACT whose prepare_start_lsn lies
> > beyond the point recovery has reached. In other words, recovery should keep
> > anachro
And now it also passes tests.
Still learning about the git way of generating PostgreSQL patches,
that's why there are two separate ones
On Sun, Jul 6, 2025 at 4:30 PM Hannu Krosing wrote:
>
> Managed to send wrong patch earlier, this one actually compiles
>
> On Sun, Jul 6, 2025 at 1:48 PM Hannu
On Wed, Dec 18, 2024 at 03:17:36PM +0900, Michael Paquier wrote:
> Done.
This new PQservice() function from commit 4b99fed75 came up in the annual
exports.txt diff. The standard in libpq has been to not clutter the API with
new functions that simply retrieve one PQconninfoOption value. PQconninf
On Thu, Jul 3, 2025 at 3:32 PM shveta malik wrote:
>
> On Wed, Jul 2, 2025 at 9:46 PM Masahiko Sawada wrote:
> >
> > On Wed, Jun 18, 2025 at 1:07 PM shveta malik wrote:
> > >
> > > On Wed, Jun 18, 2025 at 6:06 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > Thank you for the comments!
> > > >
On Sun, Jul 6, 2025 at 8:03 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> As a confirmation purpose, I did performance testing with four workloads
> we did before.
Thank you for doing the performance tests!
>
> 03. pgbench on both sides
>
> The workload is most
On Fri, Jul 4, 2025 at 8:18 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Wed, Jul 2, 2025 at 3:28 PM Hou, Zhijie wrote:
> > Kindly use the latest patch set for performance testing.
>
> During testing, we observed a limitation in cascading logical replication
> setups, such as (A -> B -> C). When retain_c
Managed to send wrong patch earlier, this one actually compiles
On Sun, Jul 6, 2025 at 1:48 PM Hannu Krosing wrote:
>
> Here is a rebased patch
>
> this time I did not indent the part under
> if(SessionReplicationRole != SESSION_REPLICATION_ROLE_REPLICA)
> {
> ... (
> }
>
> so it is immediately o
> On Sun, Jul 06, 2025 at 03:01:34PM +0200, Dmitry Dolgov wrote:
> * This way any backend between the ProcSignalBarriers will be able
> proceed with whatever it's doing, and there is need to make sure it
> will not access buffers that will soon disappear. A suggestion so far
> was to get all
> On Fri, Jul 04, 2025 at 04:41:51PM +0200, Dmitry Dolgov wrote:
> > v5-0003-Introduce-pss_barrierReceivedGeneration.patch
> >
> > 1) Do we actually need this? Isn't it enough to just have two barriers?
> >Or a barrier + condition variable, or something like that.
>
> The issue with two barrier
Hi Nathan,
Did a quick check of the patch and it seems to work ok.
What do you think of the idea of not dumping pg_shdepend here, but
instead adding the required entries after loading
pg_largeobject_metadata based on the contents of it ?
The query for this would be
WITH db AS (
SELECT oid F
Here is a rebased patch
this time I did not indent the part under
if(SessionReplicationRole != SESSION_REPLICATION_ROLE_REPLICA)
{
... (
}
so it is immediately obviuos from the patch what is added.
I can add the indent later, or just let pg_ident take care of this in due time
On Sat, May 24, 20
Dear hackers,
As a confirmation purpose, I did performance testing with four workloads
we did before.
Highlights
==
The retests on the latest patch set v46 show results consistent with previous
observations:
- There is no performance impact on the publisher side
- There is no performanc
On Tue, Jul 1, 2025 at 2:24 AM Shirisha Shirisha
wrote:
> Just wanted to follow up on the patch, any additional feedback or improvement
> in the patch would be very helpful.
Did you add the patch to the CommitFest App?
https://commitfest.postgresql.org
If not, I will recommend that to get more
Hello hackers,
A couple of the 002.blocks test's failures occurred during past three
months: [1], [2] with the following diagnostics:
# Failed test 'WAL summarizer generates statistics for WAL reads'
# at
/home/bf/bf-build/culicidae/REL_18_STABLE/pgsql/src/bin/pg_walsummary/t/002_blocks.pl
On Fri, Jul 4, 2025 at 2:41 PM Etsuro Fujita wrote:
> On Wed, Jun 18, 2025 at 8:33 PM Ranier Vilela wrote:
> > Em qua., 18 de jun. de 2025 às 07:29, Etsuro Fujita
> > escreveu:
> >> Considering fpextra cannot be NULL, I think the proposed change is
> >> something more than necessary. IMO I thi
Hi,
On Fri, Jul 4, 2025 at 9:21 PM Matheus Alcantara
wrote:
>
> The "autovacuum_max_parallel_workers" declared on guc_tables.c mention
> that is capped by "max_worker_process":
> + {
> + {"autovacuum_max_parallel_workers", PGC_SIGHUP,
> VACUUM_AUTOVACUUM,
> +
42 matches
Mail list logo
