Alvaro Herrera writes:
> On 2022-Sep-25, Tom Lane wrote:
>> I propose that we revert 4fb5c794e and instead add separate test
>> cases that just create unlogged indexes (I guess they don't actually
>> need to *do* anything with them?).
> WFM. I can do it next week, or feel free to do so if you
On 2022-Sep-25, Tom Lane wrote:
> That's what it's saying *now*, but after rereading this whole thread
> I see that it apparently said something different last week. So the
> coverage is probabilistic, which squares with this discussion and
> with some tests I just did locally. That's not good.
I wrote:
> Yeah. You can see that the coverage-test animal is not reaching it
> anymore:
> https://coverage.postgresql.org/src/backend/access/gin/ginvacuum.c.gcov.html
That's what it's saying *now*, but after rereading this whole thread
I see that it apparently said something different last
a.kozhemya...@postgrespro.ru writes:
> But my point is that after 4fb5c794e5 for most developer setups and
> buildfarm members, e.g.:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus=2022-09-25%2001%3A01%3A13
>
Yes, with MAX_CONNECTIONS=1 and -O2 the function ginbulkdelete() is
reached while the vacuum test.
But my point is that after 4fb5c794e5 for most developer setups and
buildfarm members, e.g.:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus=2022-09-25%2001%3A01%3A13
On Wed, Sep 21, 2022 at 02:10:42PM +0700, a.kozhemya...@postgrespro.ru wrote:
> After analyzing this, I found out why we don't reach that Assert but we have
> coverage shown - firstly, it reached via another test, vacuum; secondly, it
> depends on the gcc optimization flag. We reach that Assert
On 2022-Sep-21, a.kozhemya...@postgrespro.ru wrote:
> After analyzing this, I found out why we don't reach that Assert but we have
> coverage shown - firstly, it reached via another test, vacuum; secondly, it
> depends on the gcc optimization flag. We reach that Assert only when using
> -O0.
> If
After analyzing this, I found out why we don't reach that Assert but we
have coverage shown - firstly, it reached via another test, vacuum;
secondly, it depends on the gcc optimization flag. We reach that Assert
only when using -O0.
If we build with -O2 or -Og that function is not reached (due
On Wed, Sep 14, 2022 at 12:16 PM wrote:
>
> I still wonder, if assert doesn't catch why that place is marked as
> covered here?
> https://coverage.postgresql.org/src/backend/access/gin/ginvacuum.c.gcov.html
>
Probably other tests cover that.
Regards,
Amul
I still wonder, if assert doesn't catch why that place is marked as
covered here?
https://coverage.postgresql.org/src/backend/access/gin/ginvacuum.c.gcov.html
a.kozhemya...@postgrespro.ru писал 2022-09-12 15:47:
Hi,
The commit 4fb5c794e5 eliminates the ginbulkdelete() test coverage
provided
Hi,
The commit 4fb5c794e5 eliminates the ginbulkdelete() test coverage
provided by the commit 4c51a2d1e4 two years ago.
With the following Assert added:
@@ -571,7 +571,7 @@ ginbulkdelete(IndexVacuumInfo *info,
IndexBulkDeleteResult *stats,
Buffer buffer;
BlockNumber
On Sun, May 22, 2022 at 04:24:16PM +1200, Thomas Munro wrote:
> On Sat, May 21, 2022 at 6:15 PM Noah Misch wrote:
> > On Mon, Apr 25, 2022 at 10:05:08AM -0400, Tom Lane wrote:
> > > Alvaro Herrera writes:
> > > > Hmm, so 027_stream_regress.pl is not prepared to deal with any unlogged
> > > >
On Sat, May 21, 2022 at 6:15 PM Noah Misch wrote:
> On Mon, Apr 25, 2022 at 10:05:08AM -0400, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Hmm, so 027_stream_regress.pl is not prepared to deal with any unlogged
> > > tables that may be left in the regression database (which is what my
> > >
On Mon, Apr 25, 2022 at 10:05:08AM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Hmm, so 027_stream_regress.pl is not prepared to deal with any unlogged
> > tables that may be left in the regression database (which is what my
> > spgist addition did). I first tried doing a TRUNCATE of the
Alvaro Herrera writes:
> Hmm, so 027_stream_regress.pl is not prepared to deal with any unlogged
> tables that may be left in the regression database (which is what my
> spgist addition did). I first tried doing a TRUNCATE of the unlogged
> table, but that doesn't work either, and it turns out
On Mon, Apr 25, 2022 at 7:23 PM Alvaro Herrera wrote:
>
> On 2022-Apr-25, Alvaro Herrera wrote:
>
> > On 2022-Apr-25, Alvaro Herrera wrote:
> >
> > > I added one change to include spgist too, which was uncovered, and
> > > pushed this.
> >
Thanks for the commit with the improvement.
Regards,
On 2022-Apr-25, Alvaro Herrera wrote:
> On 2022-Apr-25, Alvaro Herrera wrote:
>
> > I added one change to include spgist too, which was uncovered, and
> > pushed this.
>
> Looking into the recoveryCheck failure in buildfarm.
Hmm, so 027_stream_regress.pl is not prepared to deal with any
On 2022-Apr-25, Alvaro Herrera wrote:
> I added one change to include spgist too, which was uncovered, and
> pushed this.
Looking into the recoveryCheck failure in buildfarm.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
On 2021-Nov-29, Amul Sul wrote:
> Attached patch is doing small changes to brin, gin & gist index tests
> to use an unlogged table without changing the original intention of
> those tests and that is able to hit ambuildempty() routing which is
> otherwise not reachable by the current tests.
I
On Mon, Nov 29, 2021 at 10:34 AM Amul Sul wrote:
> Hi,
>
> Attached patch is doing small changes to brin, gin & gist index tests
> to use an unlogged table without changing the original intention of
> those tests and that is able to hit ambuildempty() routing which is
> otherwise not reachable
Hi,
Attached patch is doing small changes to brin, gin & gist index tests
to use an unlogged table without changing the original intention of
those tests and that is able to hit ambuildempty() routing which is
otherwise not reachable by the current tests.
--
Regards,
Amul Sul
EDB:
21 matches
Mail list logo
