On 29.04.24 07:11, Tom Lane wrote:
Up to now, we've only worried about whether tests running in parallel
within a single test suite can interact. It's quite scary to think
that the meson setup has expanded the possibility of interactions
to our entire source tree. Maybe that was a bad idea and
Richard Guo writes:
> +1. I'm kind of worried that the expansion of parallelization could
> lead to more instances of instability. Alexander mentioned one such
> case at [1]. I haven't looked into it though.
> [1]
> https://www.postgresql.org/message-id/cbf0156f-5aa1-91db-5802-82435dda03e6%40g
On Tue, Apr 30, 2024 at 6:43 AM Michael Paquier wrote:
> I'd be curious about any discussion involving the structure of the
> meson tests.
+1. I'm kind of worried that the expansion of parallelization could
lead to more instances of instability. Alexander mentioned one such
case at [1]. I ha
On Mon, Apr 29, 2024 at 9:45 PM Tom Lane wrote:
> Richard Guo writes:
> > I noticed that some TAP tests from recovery and subscription would
> > select the count from pg_prepared_xacts. I wonder if these tests would
> > be affected if there are any prepared transactions on the backend.
>
> TAP
On Mon, Apr 29, 2024 at 09:45:16AM -0400, Tom Lane wrote:
> TAP tests shouldn't be at risk, because there is no "make
> installcheck" equivalent for them. Each TAP test creates its own
> database instance (or maybe several), so that instance won't have
> anything else going on.
There are a few mo
Richard Guo writes:
> I noticed that some TAP tests from recovery and subscription would
> select the count from pg_prepared_xacts. I wonder if these tests would
> be affected if there are any prepared transactions on the backend.
TAP tests shouldn't be at risk, because there is no "make
install
On Mon, Apr 29, 2024 at 05:11:19PM +0800, Richard Guo wrote:
> I noticed that some TAP tests from recovery and subscription would
> select the count from pg_prepared_xacts. I wonder if these tests would
> be affected if there are any prepared transactions on the backend.
TAP tests run in isolatio
On Mon, Apr 29, 2024 at 2:58 PM Michael Paquier wrote:
> On Mon, Apr 29, 2024 at 01:32:40AM -0400, Tom Lane wrote:
> > (BTW, on the same logic, should ecpg's twophase.pgc be using a
> > prepared-transaction name that's less generic than "gxid"?)
>
> I've hesitated a few seconds about that before
On Mon, Apr 29, 2024 at 1:11 PM Tom Lane wrote:
> Up to now, we've only worried about whether tests running in parallel
> within a single test suite can interact. It's quite scary to think
> that the meson setup has expanded the possibility of interactions
> to our entire source tree. Maybe tha
On Mon, Apr 29, 2024 at 01:32:40AM -0400, Tom Lane wrote:
> (BTW, on the same logic, should ecpg's twophase.pgc be using a
> prepared-transaction name that's less generic than "gxid"?)
I've hesitated a few seconds about that before sending my patch, but
refrained because this stuff does not care a
Michael Paquier writes:
> I don't disagree with your point, still I'm not sure that this can be
> made entirely bullet-proof. Anyway, I think that we should still
> improve this test and make it more robust for parallel operations:
> installcheck fails equally on HEAD if there is a prepared trans
Hello Tom and Michael,
29.04.2024 08:11, Tom Lane wrote:
Michael Paquier writes:
If you grep the source tree, you'd notice that a prepared transaction
named gxid only exists in the 2PC tests of ECPG, in
src/interfaces/ecpg/test/sql/twophase.pgc. So the origin of the
failure comes from a race
On Mon, Apr 29, 2024 at 01:11:00AM -0400, Tom Lane wrote:
> Up to now, we've only worried about whether tests running in parallel
> within a single test suite can interact. It's quite scary to think
> that the meson setup has expanded the possibility of interactions
> to our entire source tree. M
Michael Paquier writes:
> If you grep the source tree, you'd notice that a prepared transaction
> named gxid only exists in the 2PC tests of ECPG, in
> src/interfaces/ecpg/test/sql/twophase.pgc. So the origin of the
> failure comes from a race condition due to test parallelization,
> because the
Hello Richard,
29.04.2024 04:12, Richard Guo wrote:
Does anyone have any clue to this failure?
FWIW, after another run of this test, the failure just disappears. Does
it suggest that the test case is flaky?
I think this could be caused by the ecpg test twophase executed
simultaneously with
On Mon, Apr 29, 2024 at 09:12:48AM +0800, Richard Guo wrote:
> Does anyone have any clue to this failure?
>
> FWIW, after another run of this test, the failure just disappears. Does
> it suggest that the test case is flaky?
If you grep the source tree, you'd notice that a prepared transaction
na
16 matches
Mail list logo
