On Mon, Jul 21, 2025 at 11:53:00AM +0300, Nazir Bilal Yavuz wrote:
> I realized that we actually don't trim the file, we do the opposite;
> read the file from both ends. Sorry for not realizing earlier. I will
> update the remaining patches according to that but I think trim_file()
> is helpful, to
On Fri, Jul 18, 2025 at 3:17 PM Noah Misch wrote:
> > This comment is useful, but if I were to be critical, it does a better
> > job saying what this field isn't than what it is.
>
> True. I've changed it to this:
That looks great.
> - /* To have a stable sort order, break ties for some o
Hi,
On Sat, 19 Jul 2025 at 09:06, Michael Paquier wrote:
>
> The structure is strange, it seems to me that we should target things
> so as we have only one PG_TEST_FILE_TRIM_LINES defined in the tree,
> not two with one local to 027.
I see your point. Then the problem is regression_log_helper()
Hi,
On Sat, 19 Jul 2025 at 09:06, Michael Paquier wrote:
>
> This one looks acceptable to me, so applied to begin with something,
> splitting things into two pieces for clarity with some tweaks. I have
> changed things to use system_log() at the end, with fat-commas to link
> the long options an
Michael Paquier writes:
> On Fri, Jul 18, 2025 at 11:57:07AM +0300, Nazir Bilal Yavuz wrote:
>> I added that as 0001. I used a shifting method for the 'tail'
>> direction to not use too much memory. I found that there is
>> 'File::ReadBackwards' in Perl but you need to install it, so I didn't
>> u
ine_count' as an argument but
> 'PG_TEST_FILE_TRIM_LINES' environment variable overrides it. Should I
> document 'PG_TEST_FILE_TRIM_LINES' somewhere?
Documentation is required in regress.sgml, yes.
> 0002: 'Improve error reporting in 027_stream_regress test
he second attached patch. The drawback is storing five more fields in
> > pg_dump memory: oprleft, oprright, opcmethod, opfmethod, and collencoding.
> > That seems minor relative to existing pg_dump memory efficiency. Since this
> > is a source of test flakes in v18, I'd like t
Hi,
On Thu, 17 Jul 2025 at 03:08, Michael Paquier wrote:
>
> On Wed, Jul 16, 2025 at 02:32:53PM +0300, Nazir Bilal Yavuz wrote:
> > On Wed, 16 Jul 2025 at 04:39, Michael Paquier wrote:
> >> Hmm. Is that actually useful as we know that the standby has been
> >> sta
e to existing pg_dump memory efficiency. Since this
> is a source of test flakes in v18, I'd like to back-patch to v18. I'm not
> sure why the buildfarm hasn't seen the above diff, but I expect the diff could
> happen there. This is another nice win for the new test from com
On Wed, Jul 16, 2025 at 02:32:53PM +0300, Nazir Bilal Yavuz wrote:
> On Wed, 16 Jul 2025 at 04:39, Michael Paquier wrote:
>> Hmm. Is that actually useful as we know that the standby has been
>> stalen down when running the test? Even if we report something, we
>> could a
needs to dig into to find out
> what's wrong.
>
> > I agree with you. So, the current logic is:
> >
> > If primary is not alive: Do not report anything.
>
> Okay.
>
> > If only primary is alive: Report the entire diff file.
>
> Hmm. Is that actually
anything.
Okay.
> If only primary is alive: Report the entire diff file.
Hmm. Is that actually useful as we know that the standby has been
stalen down when running the test? Even if we report something, we
could always trim the output, like the standby case.
> If both primary and standby are
A 002_pg_upgrade.pl run got swapped order of tags "notnull_tbl1_upg nn" and
"notnull_parent_upg nn" for the schema diff test that commit
172259afb563d35001410dc6daad78b250924038 added in v18:
@@ -436873,14 +436873,14 @@
ALTER TABLE public.insert_tbl
ADD CONSTRAINT ne_
BLE: 1
master: 54
-- Total: 76
(Counting test failures only, excluding indent-check, Configure, Build
errors.)
# SELECT COUNT(*) FROM (SELECT DISTINCT issue_link FROM failures WHERE
dt >= '2025-06-01' AND dt < '2025-07-01');
12
# SELECT issue_link, COUNT(*) FROM failures W
Hi,
On Mon, 30 Jun 2025 at 18:01, Andres Freund wrote:
>
> Hi,
>
> On 2025-06-30 16:01:04 +0300, Nazir Bilal Yavuz wrote:
> > This patch aims to improve 027_stream_regress test's regression test
> > error reporting per Andres' suggestion [1].
>
> Thank
Hi,
On 2025-06-30 16:01:04 +0300, Nazir Bilal Yavuz wrote:
> This patch aims to improve 027_stream_regress test's regression test
> error reporting per Andres' suggestion [1].
Thanks for working on that!
One thing I don't yet like is that I think we should report if
Hi,
This patch aims to improve 027_stream_regress test's regression test
error reporting per Andres' suggestion [1]. It basically dumps 50
lines from head and tail of the regression.diff file to the failure
message if both primary and standby is alive and the regression test
is faile
On Fri, Jun 20, 2025 at 04:20:21PM +0900, Michael Paquier wrote:
> Coming back to this thread as v19 is going to open up rather soon, the
> suggestion from Tom seems to be the consensus reached, which is to use
> the same value of log_line_prefix in the CI and the TAP as in
> pg_regress.c. Attache
out
> >>> pg_ci_base.conf? We have the following line there, exposing this
> >>> configuration with TEMP_CONFIG:
> >>> src/tools/ci/pg_ci_base.conf:log_line_prefix = '%m [%p][%b] %q[%a][%v:%x]
> >>> '
> >>
> >>> T
which is to use
the same value of log_line_prefix in the CI and the TAP as in
pg_regress.c. Attached is a patch to do so, that I'd like to apply on
HEAD once v19 opens up.
If anybody would prefer a backpatch or if anybody has any comments,
please feel free.
--
Michael
diff --git a/src/test/perl/Postg
25
-- Total: 83
(Counting test failures only, excluding indent-check, Configure, Build
errors.)
# SELECT COUNT(*) FROM (SELECT DISTINCT issue_link FROM failures WHERE
dt >= '2025-05-01' AND dt < '2025-06-01');
14
# SELECT issue_link, count(*) FROM failures WHERE dt >=
On Mon, 26 May 2025 at 13:59, Michael Paquier wrote:
>
> On Sat, May 24, 2025 at 11:27:05AM +0530, Amit Kapila wrote:
> > On Sat, May 24, 2025 at 6:07 AM Michael Paquier wrote:
> >> Yes, agreed that your suggested fix looks sensible with an extra check
> >> for pg_prepared_xacts on the subscriber
On Sat, May 24, 2025 at 11:27:05AM +0530, Amit Kapila wrote:
> On Sat, May 24, 2025 at 6:07 AM Michael Paquier wrote:
>> Yes, agreed that your suggested fix looks sensible with an extra check
>> for pg_prepared_xacts on the subscriber side that can be useful for
>> debugging.
>
> +1.
Applied dow
On Sat, May 24, 2025 at 6:07 AM Michael Paquier wrote:
>
>
> Yes, agreed that your suggested fix looks sensible with an extra check
> for pg_prepared_xacts on the subscriber side that can be useful for
> debugging.
>
+1.
--
With Regards,
Amit Kapila.
behavior is provided at
> 021_two_phase_test_failure_reproduce.patch. The test can be fixed by
> explicitly waiting for both subscriptions to catch up before dropping
> either. A patch implementing this fix is attached.
+if (parsed->twophase_xid && strcmp(parsed->twophase_gid, "mygid") == 0 &&
this
>>> configuration with TEMP_CONFIG:
>>> src/tools/ci/pg_ci_base.conf:log_line_prefix = '%m [%p][%b] %q[%a][%v:%x] '
>>
>>> The two other ones are:
>>> src/test/perl/PostgreSQL/Test/Cluster.pm: '%m [%p] %q%a '
>>> src
Hi,
The 021_twophase test has failed on Kestrel at [1] with the following error:
# Failed test 'should be no prepared transactions on subscriber'
# at
/home/bf/bf-build/kestrel/HEAD/pgsql/src/test/subscription/t/021_twophase.pl
line 438.
# got: '1'
# expect
there, exposing this
configuration with TEMP_CONFIG:
src/tools/ci/pg_ci_base.conf:log_line_prefix = '%m [%p][%b] %q[%a][%v:%x] '
The two other ones are:
src/test/perl/PostgreSQL/Test/Cluster.pm: '%m [%p] %q%a '
src/test/regress/pg_regress.c: '%m %b[%p] %q%a '
Perha
> configuration with TEMP_CONFIG:
> src/tools/ci/pg_ci_base.conf:log_line_prefix = '%m [%p][%b] %q[%a][%v:%x] '
> The two other ones are:
> src/test/perl/PostgreSQL/Test/Cluster.pm: '%m [%p] %q%a '
> src/test/regress/pg_regress.c: '%m %b[%p] %q%a '
> Pe
/ci/pg_ci_base.conf:log_line_prefix = '%m [%p][%b] %q[%a][%v:%x] '
The two other ones are:
src/test/perl/PostgreSQL/Test/Cluster.pm: '%m [%p] %q%a '
src/test/regress/pg_regress.c: '%m %b[%p] %q%a '
Perhaps it would be better to apply the same configuration as the CI
by de
> On 21 May 2025, at 04:48, Michael Paquier wrote:
>
> On Wed, May 21, 2025 at 11:41:18AM +0900, Fujii Masao wrote:
>> Since pg_regress uses log_line_prefix = '%m %b[%p] %q%a ',
>> isn't it better to use the same setting in TAP tests as well?
>
> Oh, right, good point. I've managed to miss this
On Wed, May 21, 2025 at 11:41:18AM +0900, Fujii Masao wrote:
> Since pg_regress uses log_line_prefix = '%m %b[%p] %q%a ',
> isn't it better to use the same setting in TAP tests as well?
Oh, right, good point. I've managed to miss this part in
pg_regress.c. Using the same value makes even more se
On Wed, May 21, 2025 at 8:51 AM Michael Paquier wrote:
>
> Hi all,
>
> While navigating through the logs in the CI, the buildfarm, or even my
> own machine, I've found myself spending a lot of time looking at
> very specific log entries to find out the PID of a specific process,
> sometimes mistak
kend_type with a PID. That
increases the quantity of the logs, of course, but I'm finding that
really helpful to have. But perhaps it's only me?
Thanks,
--
Michael
diff --git a/src/test/perl/PostgreSQL/Test/Cluster.pm b/src/test/perl/PostgreSQL/Test/Cluster.pm
index 1c11750ac1d0..3bbd4a
Hi,
In a rare CI failure I just noticed:
https://cirrus-ci.com/task/4901437240508416
https://api.cirrus-ci.com/v1/artifact/task/4901437240508416/testrun/build/testrun/pg_amcheck/002_nonesuch/log/regress_log_002_nonesuch
[11:38:06.031](0.000s) # Failed test 'schema exclusion pattern over
On 2025-03-12 15:56:08 +0530, Ashutosh Bapat wrote:
> Large part of your patch is renaming files which are not related to
> this patch. Can you please clean that up.
Since this has not been fixed, and the patch has not passed CI since at least
mid March, I'll close this CF entry.
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
1 - 100 of 1775 matches
Mail list logo
