On Thu, Jan 20, 2022 at 6:24 PM Andres Freund wrote:
> I wonder if the easiest way to make this test reliable would be to make the
> table a temporary one? That now uses very aggressive horizons, there's no
> bgwriter that could pin the page, etc.
Good idea, thanks. I pushed that minimal change.
Hi,
On 2022-01-20 17:23:30 +1300, Thomas Munro wrote:
> Having failed to reproduce this locally, I clicked on "re-run tests"
> all afternoon on CI until eventually I captured a failure log[1]
> there, with the smoking gun:
Phew, finally.
> Since this page doesn't require wraparound vacuuming, i
On Wed, Jan 19, 2022 at 12:08 PM Andres Freund wrote:
> On 2022-01-18 17:19:06 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > That's an extremely small shared_buffers for running the regression
> > > tests, it'd not
> > > be surprising if that provoked problems we don't otherwise see. Pe
Hi,
On 2022-01-18 17:19:06 -0500, Tom Lane wrote:
> Andres Freund writes:
> > That's an extremely small shared_buffers for running the regression tests,
> > it'd not
> > be surprising if that provoked problems we don't otherwise see. Perhaps
> > VACUUM
> > ends up skipping over a page because o
On Wed, Jan 19, 2022 at 11:19 AM Tom Lane wrote:
> Andres Freund writes:
> > Also, it's odd that there's "max_connections 25" without an equal sign. I'd
> > kind of expected that to cause an error
>
> I see that guc.c intentionally allows the equal sign to be optional.
> Too lazy to check if
Andres Freund writes:
> That's an extremely small shared_buffers for running the regression tests,
> it'd not
> be surprising if that provoked problems we don't otherwise see. Perhaps VACUUM
> ends up skipping over a page because of page contention?
Hmm, good thought. I tried running the test w
On 2022-01-18 15:15:44 -0500, Tom Lane wrote:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rorqual&dt=2022-01-18%2019%3A50%3A57
>
> That reloptions test has been there awhile, and we weren't seeing
> issues with it before. What about the replication environment
> would cause VACUUM t
Thomas Munro writes:
> Alright, I've pushed a change like that. Let's see if that clears it
> up.
Nope:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rorqual&dt=2022-01-18%2019%3A50%3A57
That reloptions test has been there awhile, and we weren't seeing
issues with it before. What ab
On Tue, Jan 18, 2022 at 11:08 AM Thomas Munro wrote:
> commit fe246d1c111d43fd60a1b0afff25ed09b7ae11eb
> Author: Michael Paquier
> Date: Fri Apr 2 09:44:42 2021 +0900
>
> Improve stability of test with vacuum_truncate in reloptions.sql
>
> Hmm... looking at that commit and the referenced di
On Tue, Jan 18, 2022 at 9:37 AM Andres Freund wrote:
> diff -w -U3 c:/cirrus/src/test/recovery/../regress/expected/reloptions.out
> c:/cirrus/src/test/recovery/results/reloptions.out
> --- c:/cirrus/src/test/recovery/../regress/expected/reloptions.out
> 2022-01-17 07:08:52.779337800 +
>
Hi,
On 2022-01-18 07:47:48 +1300, Thomas Munro wrote:
> > No idea what's going on here, but I guess that we'd better show up the
> > contents of regression.diffs in the TAP logs if it exists.
>
> Hmm. Yeah.
It already is in the regress_log_*, but I agree, it'd be good to add it to the
normal ou
Hi,
On 2022-01-17 16:02:34 +0900, Michael Paquier wrote:
> On Mon, Jan 17, 2022 at 03:35:48AM +, Thomas Munro wrote:
> > Test replay of regression tests, attempt II.
> >
> > See commit message for 123828a7fa563025d0ceee10cf1b2a253cd05319. The
> > only change this time is the order of the arg
On Mon, Jan 17, 2022 at 8:02 PM Michael Paquier wrote:
> Butterflyfish has just failed in this new test:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=butterflyfish&br=HEAD
>
> Ad the pg_regress command has failed one of the tests:
> reloptions ... FAILED
On Tue, Jan 18, 2022 at 6:24 AM Tom Lane wrote:
> I wrote:
> > I'm quite appalled that this patch has apparently added an entire new run
> > of the core regression tests to the standard check-world/buildfarm cycle.
I wonder if there is a good way to share the resulting data directory
with the pg_
I wrote:
> I'm quite appalled that this patch has apparently added an entire new run
> of the core regression tests to the standard check-world/buildfarm cycle.
Not only that, but it leaves junk that is neither cleaned by "make clean"
nor .gitignored:
$ git status
On branch master
Your branch is
Michael Paquier writes:
> On Mon, Jan 17, 2022 at 03:35:48AM +, Thomas Munro wrote:
>> Test replay of regression tests, attempt II.
> Butterflyfish has just failed in this new test:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=butterflyfish&br=HEAD
> Ad the pg_regress command
On Mon, Jan 17, 2022 at 03:35:48AM +, Thomas Munro wrote:
> Test replay of regression tests, attempt II.
>
> See commit message for 123828a7fa563025d0ceee10cf1b2a253cd05319. The
> only change this time is the order of the arguments passed to
> pg_regress. The previously version broke in the
Test replay of regression tests, attempt II.
See commit message for 123828a7fa563025d0ceee10cf1b2a253cd05319. The
only change this time is the order of the arguments passed to
pg_regress. The previously version broke in the build farm environment
due to the contents of EXTRA_REGRESS_OPTS (see al
Test replay of regression tests.
Add a new TAP test under src/test/recovery to run the standard
regression tests while a streaming replica replays the WAL. This
provides a basic workout for WAL decoding and redo code, and compares
the replicated result.
Optionally, enable (expensive) wal_consist
19 matches
Mail list logo
