> On 27 Mar 2024, at 16:26, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> The only option is to make the check opt-in via a command-line parameter for
>> use it in the main regress tests, and not use it for the contrib tests. The
>> attached v7 does that and passes CI, but I wonder if it's
Daniel Gustafsson writes:
> The only option is to make the check opt-in via a command-line parameter for
> use it in the main regress tests, and not use it for the contrib tests. The
> attached v7 does that and passes CI, but I wonder if it's worth it all with
> that restriction?
Yeah, that
> On 25 Mar 2024, at 19:48, Andres Freund wrote:
> I don't think it's that, but that the freebsd task tests the installcheck
> equivalent in meson. I haven't checked what your patch is doing, but perhaps
> the issue is that it's seeing global objects concurrently created by another
> test?
Hi,
On 2024-01-19 15:40:21 +0100, Peter Eisentraut wrote:
> On 19.01.24 15:26, Daniel Gustafsson wrote:
> > > On 18 Jan 2024, at 01:57, vignesh C wrote:
> >
> > > There are a lot of failures in CFBot at [1] with:
> >
> > > More details of the same are available at [2].
> > > Do we need to
On 19.01.24 15:26, Daniel Gustafsson wrote:
On 18 Jan 2024, at 01:57, vignesh C wrote:
There are a lot of failures in CFBot at [1] with:
More details of the same are available at [2].
Do we need to clean up the objects leftover for the reported issues in the test?
Not really, these
> On 18 Jan 2024, at 01:57, vignesh C wrote:
> There are a lot of failures in CFBot at [1] with:
> More details of the same are available at [2].
> Do we need to clean up the objects leftover for the reported issues in the
> test?
Not really, these should not need cleaning up, and it's quite
On Fri, 1 Dec 2023 at 18:23, Daniel Gustafsson wrote:
>
> > On 1 Dec 2023, at 13:19, Alvaro Herrera wrote:
> >
> > Isn't it simpler to use DROP OWNED BY in 0001?
>
> I suppose it is, I kind of like the explicit drops but we do use OWNED BY
> quite
> a lot in the regression tests so changed to
> On 1 Dec 2023, at 13:19, Alvaro Herrera wrote:
>
> Isn't it simpler to use DROP OWNED BY in 0001?
I suppose it is, I kind of like the explicit drops but we do use OWNED BY quite
a lot in the regression tests so changed to that in the attached v5.
--
Daniel Gustafsson
Isn't it simpler to use DROP OWNED BY in 0001?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Hay que recordar que la existencia en el cosmos, y particularmente la
elaboración de civilizaciones dentro de él no son, por desgracia,
nada idílicas" (Ijon Tichy)
> On 1 Dec 2023, at 12:37, Heikki Linnakangas wrote:
>
> On 01/12/2023 13:22, Daniel Gustafsson wrote:
>>> On 8 Nov 2023, at 13:32, Alvaro Herrera wrote:
>>> I suppose you're just thinking of using PQexec() or whatever, run one
>>> query with sufficient ORDER BY, save the result, and at the end
On 01/12/2023 13:22, Daniel Gustafsson wrote:
On 8 Nov 2023, at 13:32, Alvaro Herrera wrote:
I suppose you're just thinking of using PQexec() or whatever, run one
query with sufficient ORDER BY, save the result, and at the end of the
test run just run the same query and compare that they are
> On 8 Nov 2023, at 13:32, Alvaro Herrera wrote:
> I suppose you're just thinking of using PQexec() or whatever, run one
> query with sufficient ORDER BY, save the result, and at the end of the
> test run just run the same query and compare that they are cell-by-cell
> identical? This sounds a
> On 8 Nov 2023, at 13:32, Alvaro Herrera wrote:
>
> On 2023-Nov-08, Daniel Gustafsson wrote:
>
>> Since test_setup.sql is part of the regress schedule and not pg_regress we
>> would have to implement this for each test run (regress, contribs etc), which
>> is what Peter didn't like about the
On 2023-Nov-08, Daniel Gustafsson wrote:
> Since test_setup.sql is part of the regress schedule and not pg_regress we
> would have to implement this for each test run (regress, contribs etc), which
> is what Peter didn't like about the original suggestion.
Oh, somehow that aspect of his reply
> On 8 Nov 2023, at 12:42, Alvaro Herrera wrote:
> On 2023-Nov-08, Peter Eisentraut wrote:
>> I think the earlier idea of just counting roles, tablespaces, etc. before
>> and after would be sufficient.
>
> Maybe record global objects in a permanent table in test_setup.sql
Since test_setup.sql
> On 8 Nov 2023, at 08:55, Peter Eisentraut wrote:
>
> On 06.07.23 00:00, Daniel Gustafsson wrote:
>>> On 16 May 2023, at 11:17, Daniel Gustafsson wrote:
>>> Parked in the July CF for now.
>> Rebased to fix a trivial conflict highlighted by the CFBot.
>
> I think the problem with this approach
On 2023-Nov-08, Peter Eisentraut wrote:
> I think the earlier idea of just counting roles, tablespaces, etc. before
> and after would be sufficient.
Maybe record global objects in a permanent table in test_setup.sql
create table global_objs as
select 'role', rolname from pg_roles
union all
On 06.07.23 00:00, Daniel Gustafsson wrote:
On 16 May 2023, at 11:17, Daniel Gustafsson wrote:
Parked in the July CF for now.
Rebased to fix a trivial conflict highlighted by the CFBot.
I think the problem with this approach is that one would need to reapply
it to each regression test
> On 16 May 2023, at 11:17, Daniel Gustafsson wrote:
> Parked in the July CF for now.
Rebased to fix a trivial conflict highlighted by the CFBot.
--
Daniel Gustafsson
v3-0001-pg_regress-Add-database-verification-test.patch
Description: Binary data
> On 15 May 2023, at 10:59, Daniel Gustafsson wrote:
> Looking at this I also found a bug introduced in the TAP format patch, which
> made failed single run tests report as 0ms due to the parameters being mixed
> up
> in the report function call. This is in 0002, which I'll apply to HEAD
>
> On 30 Mar 2023, at 22:29, Tom Lane wrote:
> Well, we could do "select rolname from pg_roles order by 1" and
> actually compare the results of the two selects. That might be
> advisable anyway, in order to produce a complaint with useful
> detail when there is something wrong.
I took a look
> On 30 Mar 2023, at 22:29, Tom Lane wrote:
> Daniel Gustafsson writes:
>>> On 30 Mar 2023, at 20:44, Tom Lane wrote:
>>> Another idea could be for pg_regress to enforce that "select count(*)
>>> from pg_roles" gives the same answer before and after the test run.
>
>> That wouldn't prevent
Daniel Gustafsson writes:
>> On 30 Mar 2023, at 20:44, Tom Lane wrote:
>> Maybe it'd be close enough to expect there to be no roles named
>> "regress_xxx". In combination with
>> -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, that would prevent us
>> from accidentally leaving stuff behind, and we
> On 30 Mar 2023, at 20:44, Tom Lane wrote:
> Maybe it'd be close enough to expect there to be no roles named
> "regress_xxx". In combination with
> -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, that would prevent us
> from accidentally leaving stuff behind, and we could hope that it doesn't
>
Robert Haas writes:
> On Thu, Mar 30, 2023 at 1:07 PM Tom Lane wrote:
>> This oversight broke repeated runs of "make installcheck".
> GH. You would think that I would have learned better by now, but
> evidently not. Is there some way we can add an automated guard against
> this?
Hm. We
On Thu, Mar 30, 2023 at 1:07 PM Tom Lane wrote:
> Clean up role created in new subscription test.
>
> This oversight broke repeated runs of "make installcheck".
GH. You would think that I would have learned better by now, but
evidently not. Is there some way we can add an automated guard
26 matches
Mail list logo
