61
-- Total: 284
(Counting test failures only, excluding indent-check, Configure, Build
errors.)
# SELECT COUNT(*) FROM (SELECT DISTINCT issue_link FROM failures WHERE
dt >= '2025-04-01' AND dt < '2025-05-01');
33
# SELECT issue_link, count(*) FROM failures WHER
On Tue, Apr 22, 2025 at 06:22:51AM +, Bertrand Drouvot wrote:
> Yeah, unless that might come from fc415edf8ca but I don't think that's the
> case.
I've been eyeing this whole area of the code for a few hours to
convince myself on HEAD, and I cannot really find a defect directly
related to it.
On Tue, 22 Apr 2025 at 22:25, Tom Lane wrote:
>
> Pavel Borisov writes:
> > On Tue, 22 Apr 2025 at 21:13, Tom Lane wrote:
> >> BTW, you forgot to update expected/float4-misrounded-input.out.
>
> > Added in v3. Thanks for a mention!
>
> v3 LGTM, pushed.
Thank you!
Regards,
Pavel
Pavel Borisov writes:
> On Tue, 22 Apr 2025 at 21:13, Tom Lane wrote:
>> BTW, you forgot to update expected/float4-misrounded-input.out.
> Added in v3. Thanks for a mention!
v3 LGTM, pushed.
regards, tom lane
> heap-specific. You can see in the following fragment, updated rows jump
> >>>> to
> >>>> the bottom.
>
> >>> I'd be willing to consider a policy that we don't want to depend on
> >>> exactly where UPDATE moves rows to.
willing to consider a policy that we don't want to depend on
>>> exactly where UPDATE moves rows to. The proposed patch is not that,
>>> however.
>> OK, that makes sense for me.
> Thanks for this input!
> This was my first intention to fix only the test that
;d be willing to consider a policy that we don't want to depend on
> > exactly where UPDATE moves rows to. The proposed patch is not that,
> > however.
>
> OK, that makes sense for me.
Thanks for this input!
This was my first intention to fix only the test that was affected
On Tue, Apr 22, 2025 at 7:20 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'd like to add that float4.out not only assumes that insert-ordering is
> > preserved (this could be more-or-less portable between table AMs). It also
> > assumes the way UPDATE moves updated rows. That seems quit
Alexander Korotkov writes:
> I'd like to add that float4.out not only assumes that insert-ordering is
> preserved (this could be more-or-less portable between table AMs). It also
> assumes the way UPDATE moves updated rows. That seems quite
> heap-specific. You can see in the following fragment
eserve insertion order would break every single
> > > one of our regression tests. (I speak from experience, as
> > > Salesforce had to deal with this when I was there...)
> > >
> > > The reason why we don't simply add ORDER BY to everything is
> > >
ts. (I speak from experience, as
> > Salesforce had to deal with this when I was there...)
> >
> > The reason why we don't simply add ORDER BY to everything is
> > explained at [1]:
> >
> > You might wonder why we don't order all the regression
y we don't simply add ORDER BY to everything is
> explained at [1]:
>
> You might wonder why we don't order all the regression test
> queries explicitly to get rid of this issue once and for all. The
> reason is that that would make the regression tests less use
er all the regression test
queries explicitly to get rid of this issue once and for all. The
reason is that that would make the regression tests less useful,
not more, since they'd tend to exercise query plan types that
produce ordered results to the exclusion of those that don
Hi Pavel,
> It's not a big problem, but propose a simple fix for the tests. It
> just adds ORDER BY 1 to all relevant float4 and floa8 queries.
Thanks for the patch. That's a good change IMO.
> I don't
> have a strong opinion about backpatching this, but as the patch
> changes only regression te
Hi, hackers!
I noticed that SELECT results in float4 and float8 tests lack ORDER BY
clauses. This makes test results depend on the current heap/MVCC
implementation.
If I try to run the float8 test on a table created with a different
access method provided by an extension, I'm getting re
Hi,
On Mon, Apr 21, 2025 at 10:17:40AM +0900, Michael Paquier wrote:
> On Tue, Apr 15, 2025 at 05:50:32AM +, Bertrand Drouvot wrote:
> > Sorry, can't look at the details right now but it might be linked to
> > 039549d70f6 which is recent enough and in this area. Will give it a look
> > once
Dear Andrew,
> What is that extra stuff doing on the end of your LD_LIBRARY_PATH?
> That looks wrong. Do you have LD_LIBRARY_PATH set in your calling environment?
To confirm, did you ask the LD_LIBRARY_PATH on my bash? Here it is:
```bash
$ echo $LD_LIBRARY_PATH
/usr/local/pgsql/lib:/usr/local/
On 2025-04-21 Mo 7:42 AM, Hayato Kuroda (Fujitsu) wrote:
I also checked PATH/LD_LIBRARY_PATH and they looked correct.
PATH=/home/hayato/builddir/tmp_install//usr/local/pgsql/bin:/home/hayato/builddir/src/test/regress:/usr/local/pgsql/bin/:...
LD_LIBRARY_PATH=/home/hayato/builddir/tmp_install
ld not do the check because the psql command could not be start or it
exit immediately with the symbol lookup error.
Not sure it is meaningful, but I attached the execution log of ldd command, with
the same PATH/LD_LIBRARY_PATH while doing a meson test.
> And meson-logs/testlog.txt shows that the
On Tue, Apr 15, 2025 at 05:50:32AM +, Bertrand Drouvot wrote:
> Sorry, can't look at the details right now but it might be linked to
> 039549d70f6 which is recent enough and in this area. Will give it a look once
> I've time.
Playing catch-up with various things this week, and I have been
loo
Dear Kuroda-san,
16.04.2025 11:12, Hayato Kuroda (Fujitsu) wrote:
Dear Richard, Alexander,
FYI - I felt there is a same type of failure [1] for REL_17_STABLE, added in
the wikipage.
Feel free to revert it if I did something wrong.
[1]:https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl
Dear Richard, Alexander,
FYI - I felt there is a same type of failure [1] for REL_17_STABLE, added in
the wikipage.
Feel free to revert it if I did something wrong.
[1]:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=prion&dt=2025-04-15%2016%3A16%3A06&stg=recovery-check
Best reg
On Wed, Apr 16, 2025 at 1:00 PM Alexander Lakhin wrote:
> 16.04.2025 06:05, Richard Guo wrote:
> On Wed, Apr 16, 2025 at 11:54 AM Richard Guo wrote:
> I noticed this recoveryCheck test failure on flaviventris after
> pushing commit 3b35f9a4c (Fix an incorrect check in get_
Hello Richard,
16.04.2025 06:05, Richard Guo wrote:
On Wed, Apr 16, 2025 at 11:54 AM Richard Guo wrote:
I noticed this recoveryCheck test failure on flaviventris after
pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path).
...
I'm not convinced this failure is relat
On Wed, Apr 16, 2025 at 11:54 AM Richard Guo wrote:
> I noticed this recoveryCheck test failure on flaviventris after
> pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path).
>
> ### Reloading node "standby"
> # Running: pg_ctl --pgdata xxx/pgdata
I noticed this recoveryCheck test failure on flaviventris after
pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path).
### Reloading node "standby"
# Running: pg_ctl --pgdata xxx/pgdata reload
server signaled
### Restarting node "standby"
# Running: pg_ctl
Hi,
On 2025-04-15 06:04:54 -0400, Andres Freund wrote:
> See also
> https://postgr.es/m/dwrkeszz6czvtkxzr5mqlciy652zau5qqnm3cp5f3p2po74ppk%40omg4g3cc6dgq
Huh, turns out my emails of the last few days had gotten stuck. I only noticed
when trying to open the above link and it was dead. I had been
Hi,
On 2025-04-14 22:58:28 -0400, Tom Lane wrote:
> In the last day or so, both skink and mamba have hit this
> in the pg_rewind test suite [1][2]:
>
> #3 0x01f03f7c in ExceptionalCondition
> (conditionName=conditionName@entry=0x2119c4c "pending_since == 0",
Hi,
On Tue, Apr 15, 2025 at 08:00:00AM +0300, Alexander Lakhin wrote:
> Hello Tom,
>
> 15.04.2025 05:58, Tom Lane wrote:
> > In the last day or so, both skink and mamba have hit this
> > in the pg_rewind test suite [1][2]:
> >
> > #3 0x01f03f7c in Excepti
On Mon, Apr 14, 2025 at 10:58:28PM -0400, Tom Lane wrote:
> That assert appears to be several years old, and the
> 008_min_recovery_point.pl test script that's triggering it hasn't
> changed very recently either, so I'm baffled where to start digging.
> It has the o
Hello Tom,
15.04.2025 05:58, Tom Lane wrote:
In the last day or so, both skink and mamba have hit this
in the pg_rewind test suite [1][2]:
#3 0x01f03f7c in ExceptionalCondition (conditionName=conditionName@entry=0x2119c4c
"pending_since == 0", fileName=fileName@entry=0x2119454
In the last day or so, both skink and mamba have hit this
in the pg_rewind test suite [1][2]:
#3 0x01f03f7c in ExceptionalCondition
(conditionName=conditionName@entry=0x2119c4c "pending_since == 0",
fileName=fileName@entry=0x2119454 "pgstat.c", lineNumber=lineNumber@entry=
roduce the failure with steps:
>
> 1. install old PG, e.g., PG16. To your system. .so file must be put on your
> $$LD_LIBRARY_PATH.
> 2. build newer PG, e.g., master, with meson build system [1].
> 3. run regression test and ERROR would be reported [2].
>
> This issue does
your
$$LD_LIBRARY_PATH.
2. build newer PG, e.g., master, with meson build system [1].
3. run regression test and ERROR would be reported [2].
This issue does not happen when I used autoconf/make build system.
Analysis
=
According to the log, the instance could be started but psql could not
I wrote:
> Dmitrii Bondar writes:
>> I considered removing it entirely, but that seemed too drastic a
>> solution (and, at the very least, I don't have enough expertise to make
>> that decision).
> I'm not that thrilled with giving up on refint.c either. But in its
> current state, it's a pret
Dmitrii Bondar writes:
> On 04/04/2025 01:11, Tom Lane wrote:
>> So that's a long laundry list and we haven't even dug hard.
>> Is it worth it? If you feel like doing the legwork then
>> I'm willing to support the project, but I really wonder if
>> we shouldn't cut our losses and just remove the
and generate a
new schedule file dynamically. We don't need to maintain a separate
schedule file.
You're right that if an existing uninteresting test is modified to
create interesting objects, we'd lose coverage of those objects. That
seems a much smaller problem to me. So it&#
Greetings, everyone!
When you try to run installcheck using a cluster that was initialized
with ICU (./initdb -D ../data --locale-provider=icu
--icu-locale='en_US_POSIX') and NO_LOCALE=1 you get a warning:
# +++ regress install-check in src/test/regress +++
# using
Hi,
I tested the "not enforced" constraint feature extensively today
especially the cases of partitioned table. Everything seems to be
working fine.
While doing that, I found that foreign_key.sql does not have a test to
make sure that a partition continues to have the constraints i
On Mon, Mar 24, 2025 at 5:44 PM Alvaro Herrera wrote:
>
> On 2025-Mar-24, Ashutosh Bapat wrote:
>
> > One concern I have with directory format is the dumped database is not
> > readable. This might make investigating a but identified the test a
> > bit more complex
Hi,
On 2025-03-24 02:26:35 +0900, Fujii Masao wrote:
> > With autovacuum = off, all of these fluctuations go away.
>
> So you are suggesting disabling autovacuum during the postgres_fdw regression
> test?
I don't think that's a good fix in this case.
> Just my ide
On Thu, Mar 20, 2025 at 10:09 PM Alvaro Herrera wrote:
>
> On 2025-Mar-20, vignesh C wrote:
>
> > Will it help the execution time if we use --jobs in case of pg_dump
> > and pg_restore wherever supported:
>
> As I said in another thread, I think we should enable
ht keep a list of the slow tests that don't leave any useful object
> behind, then filter parallel_schedule to exclude those; this ensures
> test files created in the future are still used.)
I'm not much a fan of approaches that require an extra schedule,
because this is prone to fo
itfest entry please. Better to add an open item on the wiki
page.
https://wiki.postgresql.org/wiki/Open_Items
> Yes. Few animals that I sampled, the test is finishing pretty early
> even though it's taking longer than many other tests. But it's not the
> longest. I also looked a
ics dump/restore [1]. As Daniel has expressed upthread [2], we
> > > should go ahead and commit the test even if the bug is not fixed. But
> > > in case it creates a lot of noise and makes the build farm red, we
> > > could suppress the failure by not dumping s
On 2025-Apr-03, Andres Freund wrote:
> I've increased the timeout even further, but I can't say that I am happy about
> the slowest test getting even slower. Adding test time in the serially slowest
> test is way worse than adding the same time in a concurrent test.
On Thu, Apr 3, 2025 at 1:50 PM Alvaro Herrera wrote:
>
> On 2025-Apr-03, Ashutosh Bapat wrote:
>
> > Looks like the problem is in the test itself as pointed out by Jeff in
> > [1]. PFA patch fixing the test and enabling statistics back.
>
> Thanks, pushed.
Thanks.
where.
>
>
> And this really affects the overall test time:
>
> All tests before:
> real1m38.173s
> user5m52.500s
> sys 4m23.574s
>
> All tests after:
> real2m0.397s
> user5m53.625s
> sys 4m30.51
Hi,
On 2025-04-03 19:14:02 +0200, Alvaro Herrera wrote:
> On 2025-Apr-03, Andres Freund wrote:
>
> > I've increased the timeout even further, but I can't say that I am happy
> > about
> > the slowest test getting even slower. Adding test time in the serially
On Fri, Apr 4, 2025 at 4:41 PM Ashutosh Bapat
wrote:
>
> On Thu, Apr 3, 2025 at 10:44 PM Alvaro Herrera
> wrote:
> >
> > On 2025-Apr-03, Andres Freund wrote:
> >
> > > I've increased the timeout even further, but I can't say that I am happy
&
On Thu, Apr 3, 2025 at 10:44 PM Alvaro Herrera wrote:
>
> On 2025-Apr-03, Andres Freund wrote:
>
> > I've increased the timeout even further, but I can't say that I am happy
> > about
> > the slowest test getting even slower. Adding test time in the serial
On Thu, Apr 3, 2025 at 5:52 PM Ashutosh Bapat
wrote:
>
> Hi,
> I tested the "not enforced" constraint feature extensively today
> especially the cases of partitioned table. Everything seems to be
> working fine.
>
> While doing that, I found that foreign_key.sql
On 04/04/2025 01:11, Tom Lane wrote:
So that's a long laundry list and we haven't even dug hard.
Is it worth it? If you feel like doing the legwork then
I'm willing to support the project, but I really wonder if
we shouldn't cut our losses and just remove the module.
(I hesitate now to look at
Dmitrii Bondar writes:
> [ v6-0001-Triggers-test-fix-with-the-invalid-cache-in-refin.patch ]
I spent a little bit of time looking over this patch. My first
instinct was "we can't really change the recommended method of
installing these triggers" --- but that would only ma
Hi,
On 2025-04-03 10:20:09 +0200, Alvaro Herrera wrote:
> On 2025-Apr-03, Ashutosh Bapat wrote:
>
> > Looks like the problem is in the test itself as pointed out by Jeff in
> > [1]. PFA patch fixing the test and enabling statistics back.
>
> Thanks, pushed.
Since then t
On 2025-Apr-03, Ashutosh Bapat wrote:
> Looks like the problem is in the test itself as pointed out by Jeff in
> [1]. PFA patch fixing the test and enabling statistics back.
Thanks, pushed.
> A note about variable name changes and introduction of new variables.
> We run step 2 bet
will commit both the bug fix and test change to enable stats together.
Looks like the problem is in the test itself as pointed out by Jeff in
[1]. PFA patch fixing the test and enabling statistics back.
The test file is arranged as follows
1. Setup old cluster (this step also runs regression if
On Thu, Apr 3, 2025 at 9:29 AM vignesh C wrote:
>
> I believe this commitfest entry at [1] can be closed now, as the
> buildfarm has been running stably for the past few days.
> [1] - https://commitfest.postgresql.org/patch/4956/
I intended to close this but closed another entry by mistake. If
po
al change. That
> > way, we will know when statistics dump/restore has become stable.
>
> No commitfest entry please. Better to add an open item on the wiki
> page.
> https://wiki.postgresql.org/wiki/Open_Items
Posted it on the thread where I have reported the bug. Hopefully, we
wi
On Tue, Apr 1, 2025 at 10:31 PM Alvaro Herrera wrote:
>
> On 2025-Apr-01, Ashutosh Bapat wrote:
>
> > Just today morning, I found something which looks like another bug in
> > statistics dump/restore [1]. As Daniel has expressed upthread [2], we
> > should go ahead and
Thanks for pushing.
==
Kind Regards,
Peter Smith.
Fujitsu Australia
> On 1 Apr 2025, at 19:01, Alvaro Herrera wrote:
> Thanks!
Thanks for taking this one across the finishing line!
--
Daniel Gustafsson
04
-- Total: 243
(Counting test failures only, excluding indent-check, Configure, Build
errors.)
# SELECT COUNT(*) FROM (SELECT DISTINCT issue_link FROM failures WHERE
dt >= '2025-03-01' AND dt < '2025-04-01');
36
# SELECT issue_link, count(*) FROM failures WHER
On 2025-Apr-01, Ashutosh Bapat wrote:
> Just today morning, I found something which looks like another bug in
> statistics dump/restore [1]. As Daniel has expressed upthread [2], we
> should go ahead and commit the test even if the bug is not fixed. But
> in case it creates a lot
estore [1]. As Daniel has expressed upthread [2], we
should go ahead and commit the test even if the bug is not fixed. But
in case it creates a lot of noise and makes the build farm red, we
could suppress the failure by not dumping statistics for comparison
till the bug is fixed. PFA patchset which re
On 2025-Mar-31, Daniel Gustafsson wrote:
> Given where we are in the cycle, it seems to make sense to stick to using the
> schedule we already have rather than invent a new process for generating it,
> and work on that for 19?
No objections to that. I'll see about getting this committed during m
else (except maybe loading a little data).
>> I believe it'd be a lot easier to remember to add to that when
>> inventing new SQL than to remember to leave something behind from the
>> core regression tests. This would also be far faster to run than any
>> appro
anything else (except maybe loading a little data).
> > I believe it'd be a lot easier to remember to add to that when
> > inventing new SQL than to remember to leave something behind from the
> > core regression tests. This would also be far faster to run than any
> &g
On Mon, Mar 31, 2025 at 5:07 PM Ashutosh Bapat
wrote:
>
The bug related to materialized views has been fixed and now the test
passes even if we compare statistics from dumped and restored
databases. Hence removing 0003. In the attached patchset I have also
addressed Vignesh's below com
%), wrote 3
SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=12.404 s, sync=0.013 s, total=12.574 s; sync files=28,
longest=0.004 s, average=0.001 s; distance=8299 kB, estimate=8299 kB; lsn=0/2094248, redo lsn=0/1FA5A48
2025-03-14 14:44:31.119 UTC [1519026][postmaster][:0] LOG: received
amically. We don't need to maintain a separate
> schedule file.
This seems like a fundamentally broken approach to me.
The entire argument for using the core regression tests as a source of
data to test dump/restore is that, more or less "for free", we can
expect to get cove
asier to remember to add to that when
> inventing new SQL than to remember to leave something behind from the
> core regression tests. This would also be far faster to run than any
> approach that involves picking a random subset of the core test
> scripts.
FWIW this sounds closely rela
try and
> > > identify which of parallel_schedule tests leave objects behind and
> > > create a shorter schedule with only those (a possible implementation
> > > might keep a list of the slow tests that don't leave any useful object
> > > behind, then filter paralle
On Fri, Mar 28, 2025 at 4:05 PM Alvaro Herrera wrote:
>
> On 2025-Mar-28, Ashutosh Bapat wrote:
>
> > No, that's losing some information like default installation and the
> > same version.
>
> You don't need to preserve such information. This is just a
On 2025-Mar-28, Ashutosh Bapat wrote:
> No, that's losing some information like default installation and the
> same version.
You don't need to preserve such information. This is just a test name.
People looking for more details can grep for the name and they will find
the comme
Vignesh and Alvaro
On Fri, Mar 28, 2025 at 12:02 PM Ashutosh Bapat
wrote:
> >
> > Maybe
> > fail("roundtrip dump/restore of the regression database")
>
> No, that's losing some information like default installation and the
> same version.
How about "dump and restore across servers with same Post
gt; create a shorter schedule with only those (a possible implementation
> > might keep a list of the slow tests that don't leave any useful object
> > behind, then filter parallel_schedule to exclude those; this ensures
> > test files created in the future are still used.)
rrectly:
> > > + if ($src_node->pg_version != $dst_node->pg_version
> > > + or defined $src_node->{_install_path})
> > > + {
> > > + fail("same version dump and restore test using default
> > > installat
; > + or defined $src_node->{_install_path})
> > + {
> > + fail("same version dump and restore test using default
> > installation");
> > + return;
> > + }
> >
> > how about something like bel
; > > One concern I have with directory format is the dumped database is not
> > > > readable. This might make investigating a but identified the test a
> > > > bit more complex.
> > >
> > > Oh, it's readable all right. You just need to use `pg_r
readable. This might make investigating a but identified the test a
> > > bit more complex.
> >
> > Oh, it's readable all right. You just need to use `pg_restore -f-` to
> > read it. No big deal.
> >
> >
> > So I ran this a few times:
> > /usr/b
s,
Dmitrii
From f52d52fcc6c2febb54dfb6f3aa5e128bcea1 Mon Sep 17 00:00:00 2001
From: Bondar Dmitrii
Date: Thu, 27 Mar 2025 14:58:49 +0700
Subject: [PATCH v6] Triggers test fix with the invalid cache in refint.c
---
contrib/spi/refint.c | 26
doc/src/sgml/
Hi Dmitrii,
Thanks for the quick update!
On 3/26/25 02:45, Dmitrii Bondar wrote:
>> 3. Consider updating documentation for doc/src/contrib-spi.sgml, or any file
as appropriate, to
>> reflect the changes.
>
> The changes have now been added to doc/src/contrib-spi.sgml. I also added a
considerat
Hello Masao-san and Melanie,
Thank you for your attention to this!
23.03.2025 19:26, Fujii Masao wrote:
With autovacuum = off, all of these fluctuations go away.
So you are suggesting disabling autovacuum during the postgres_fdw regression
test?
No, I'd prefer to have the test s
there any cases where check_primary_key() and
check_foreign_key() should be called using a BEFORE trigger? Will this
change break backwards compatibility? Consider adding a test with a
BEFORE trigger to ensure the error "must be fired by AFTER trigger" is
raised.
The usage wit
On Sun, Mar 23, 2025 at 10:00 AM Alexander Lakhin wrote:
>
> Interestingly enough, with "log_autovacuum_min_duration = 0" added to
> TEMP_CONFIG, I can't see "automatic vacuum/analyze" messages related
> to ft2/ "S 1"."T 1", so autovacuum somehow affects contents of this table
> indirectly.
>
> Wi
alled using a BEFORE trigger? Will this change break backwards
compatibility? Consider adding a test with a BEFORE trigger to ensure the error
"must be fired by AFTER trigger" is raised.
Thank you!
The new status of this patch is: Waiting on Author
| | ft2 |
(10 rows)
EXPLAIN (verbose, costs off)
shows that the UPDATE ... RETURNING query might be unstable due to lack of
ORDER BY.
I managed to reproduce this failure locally with the attached patch
applied to make the test repeatable and with:
sed 's/REGRESS = postgres_fdw.*/REGRES
On 2025-Mar-24, Ashutosh Bapat wrote:
> One concern I have with directory format is the dumped database is not
> readable. This might make investigating a but identified the test a
> bit more complex.
Oh, it's readable all right. You just need to use `pg_restore -f-` to
read it
On 10/01/2025 05:11, Peter Smith wrote:
On Sun, Dec 8, 2024 at 10:57 AM Tomas Vondra wrote:
Yes, there are cases with logical replication where reproducing may be
expensive (in terms of data amounts, time, ...) but I don't think that's
the case here - this test is trivial/cheap.
But
> On 24 Mar 2025, at 10:54, Ashutosh Bapat wrote:
> 0003 - same as 0002 in the previous patch set. It excludes statistics
> from comparison, otherwise the test will fail because of bug reported
> at [1]. Ideally we shouldn't commit this patch so as to test
> statistics dump
tuff in any way. We need to see it in absolute
> terms: in machines similar to mine, the pg_upgrade test would go from
> taking 23s to taking 27s. This is 4s slower, but this isn't an increase
> in total test runtime, because decently run test suites run multiple
> tests in paral
hows that the UPDATE ... RETURNING query might be unstable due to lack of
ORDER BY.
I managed to reproduce this failure locally with the attached patch
applied to make the test repeatable and with:
sed 's/REGRESS = postgres_fdw.*/REGRESS = $(shell printf "postgres_fdw %.0s"
`seq 50
On Fri, Mar 21, 2025 at 6:04 PM Alvaro Herrera wrote:
>
> On 2025-Mar-21, Ashutosh Bapat wrote:
>
> > On Thu, Mar 20, 2025 at 8:37 PM vignesh C wrote:
>
> > > Should the copyright be only 2025 in this case:
>
> > The patch was posted in 2024 to this mailing list. So we better
> > protect the copy
t heard otherwise.
I don't think we need to see slowdown this in relative terms, the way we
would discuss a change in the executor. This is not a change that
would affect user-level stuff in any way. We need to see it in absolute
terms: in machines similar to mine, the pg_upgrade test would
On Fri, Mar 21, 2025 at 8:13 PM Alvaro Herrera wrote:
>
> I passed PROVE_FLAGS="--timer -v" to get the timings and run under
> --format=directory.
>
> Without new test:
> ok23400 ms ( 0.00 usr 0.00 sys + 2.84 cusr 1.53 csys = 4.37 CPU)
> ok23409 ms (
I passed PROVE_FLAGS="--timer -v" to get the timings and run under
--format=directory.
Without new test:
ok23400 ms ( 0.00 usr 0.00 sys + 2.84 cusr 1.53 csys = 4.37 CPU)
ok23409 ms ( 0.00 usr 0.01 sys + 2.81 cusr 1.53 csys = 4.35 CPU)
With new test, under --format=dire
On Thu, 13 Mar 2025 at 18:10, Heikki Linnakangas wrote:
>
>
> Hmm, this problem isn't limited to this one pg_upgrade test, right? It
> could happen with any pg_upgrade invocation. And perhaps in a running
> server too, if a relfilenumber is reused quickly. In dropdb() and
>
On Thu, 20 Mar 2025 at 22:09, Alvaro Herrera wrote:
>
> On 2025-Mar-20, vignesh C wrote:
>
> > Will it help the execution time if we use --jobs in case of pg_dump
> > and pg_restore wherever supported:
>
> As I said in another thread, I think we should enable this test
On 2025-Mar-21, Ashutosh Bapat wrote:
> On Thu, Mar 20, 2025 at 8:37 PM vignesh C wrote:
> > Should the copyright be only 2025 in this case:
> The patch was posted in 2024 to this mailing list. So we better
> protect the copyright since then. I remember a hackers discussion
> where a senior mem
1 - 100 of 1740 matches
Mail list logo
