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
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/
1 - 100 of 1757 matches
Mail list logo
