public inbox for [email protected]help / color / mirror / Atom feed
tweak to a few index tests to hits ambuildempty() routine. 15+ messages / 6 participants [nested] [flat]
* tweak to a few index tests to hits ambuildempty() routine. @ 2021-11-29 05:04 Amul Sul <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Amul Sul @ 2021-11-29 05:04 UTC (permalink / raw) To: PostgreSQL Hackers <[email protected]> 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: http://www.enterprisedb.com Attachments: [application/octet-stream] v1_index_test_for_ambuildempty.patch (3.3K, ../../CAAJ_b95nneRCLM-=qELEdgCYSk6W_++-C+Q_t+wH3SW-hF50iw@mail.gmail.com/2-v1_index_test_for_ambuildempty.patch) download | inline diff: diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out index e53d6e48856..ae4c424e79f 100644 --- a/src/test/regress/expected/brin.out +++ b/src/test/regress/expected/brin.out @@ -484,7 +484,7 @@ ERROR: block number out of range: -1 SELECT brin_summarize_range('brin_summarize_idx', 4294967296); ERROR: block number out of range: 4294967296 -- test value merging in add_value -CREATE TABLE brintest_2 (n numrange); +CREATE UNLOGGED TABLE brintest_2 (n numrange); CREATE INDEX brinidx_2 ON brintest_2 USING brin (n); INSERT INTO brintest_2 VALUES ('empty'); INSERT INTO brintest_2 VALUES (numrange(0, 2^1000::numeric)); diff --git a/src/test/regress/expected/gin.out b/src/test/regress/expected/gin.out index 6402e89c7ff..1a0c3c6167f 100644 --- a/src/test/regress/expected/gin.out +++ b/src/test/regress/expected/gin.out @@ -74,7 +74,7 @@ select count(*) > 0 as ok from gin_test_tbl where i @> array[1]; reset gin_fuzzy_search_limit; -- Test optimization of empty queries -create temp table t_gin_test_tbl(i int4[], j int4[]); +create unlogged table t_gin_test_tbl(i int4[], j int4[]); create index on t_gin_test_tbl using gin (i, j); insert into t_gin_test_tbl values diff --git a/src/test/regress/expected/gist.out b/src/test/regress/expected/gist.out index 90edb4061d4..c1af87f7f32 100644 --- a/src/test/regress/expected/gist.out +++ b/src/test/regress/expected/gist.out @@ -36,7 +36,7 @@ reindex index gist_pointidx; -- -- Test Index-only plans on GiST indexes -- -create table gist_tbl (b box, p point, c circle); +create unlogged table gist_tbl (b box, p point, c circle); insert into gist_tbl select box(point(0.05*i, 0.05*i), point(0.05*i, 0.05*i)), point(0.05*i, 0.05*i), diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql index 3bd866d947a..33a30fcf777 100644 --- a/src/test/regress/sql/brin.sql +++ b/src/test/regress/sql/brin.sql @@ -449,7 +449,7 @@ SELECT brin_summarize_range('brin_summarize_idx', -1); SELECT brin_summarize_range('brin_summarize_idx', 4294967296); -- test value merging in add_value -CREATE TABLE brintest_2 (n numrange); +CREATE UNLOGGED TABLE brintest_2 (n numrange); CREATE INDEX brinidx_2 ON brintest_2 USING brin (n); INSERT INTO brintest_2 VALUES ('empty'); INSERT INTO brintest_2 VALUES (numrange(0, 2^1000::numeric)); diff --git a/src/test/regress/sql/gin.sql b/src/test/regress/sql/gin.sql index 5194afcc1f5..746880937bb 100644 --- a/src/test/regress/sql/gin.sql +++ b/src/test/regress/sql/gin.sql @@ -52,7 +52,7 @@ select count(*) > 0 as ok from gin_test_tbl where i @> array[1]; reset gin_fuzzy_search_limit; -- Test optimization of empty queries -create temp table t_gin_test_tbl(i int4[], j int4[]); +create unlogged table t_gin_test_tbl(i int4[], j int4[]); create index on t_gin_test_tbl using gin (i, j); insert into t_gin_test_tbl values diff --git a/src/test/regress/sql/gist.sql b/src/test/regress/sql/gist.sql index b9d398ea941..3849b649a2c 100644 --- a/src/test/regress/sql/gist.sql +++ b/src/test/regress/sql/gist.sql @@ -41,7 +41,7 @@ reindex index gist_pointidx; -- Test Index-only plans on GiST indexes -- -create table gist_tbl (b box, p point, c circle); +create unlogged table gist_tbl (b box, p point, c circle); insert into gist_tbl select box(point(0.05*i, 0.05*i), point(0.05*i, 0.05*i)), ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-05-21 06:15 Noah Misch <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Noah Misch @ 2022-05-21 06:15 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, Apr 25, 2022 at 10:05:08AM -0400, Tom Lane wrote: > Alvaro Herrera <[email protected]> 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 that the > > regression database does not have any UNLOGGED relations. Maybe that's > > something we need to cater for, eventually, but for now dropping the > > table suffices. I have pushed that. > > It does seem like the onus should be on 027_stream_regress.pl to > deal with that, rather than restricting what the core tests can > leave behind. Yeah. Using "pg_dumpall --no-unlogged-table-data", as attached, suffices. > Maybe we could have it look for unlogged tables and drop them > before making the dumps? Although I don't understand why > TRUNCATE wouldn't do the job equally well. After TRUNCATE, one still gets a setval for sequences and a zero-row COPY for tables. When dumping a standby or using --no-unlogged-table-data, those commands are absent. Author: Noah Misch <[email protected]> Commit: Noah Misch <[email protected]> Use --no-unlogged-table-data in t/027_stream_regress.pl. This removes the need to drop unlogged relations in the src/test/regress suite, like commit dec8ad367e46180f826d5b6dc820fbecba1b71d2 did. Reviewed by FIXME. Discussion: https://postgr.es/m/[email protected] diff --git a/src/test/recovery/t/027_stream_regress.pl b/src/test/recovery/t/027_stream_regress.pl index fdb4ea0..7982ac0 100644 --- a/src/test/recovery/t/027_stream_regress.pl +++ b/src/test/recovery/t/027_stream_regress.pl @@ -100,7 +100,8 @@ $node_primary->wait_for_catchup($node_standby_1, 'replay', command_ok( [ 'pg_dumpall', '-f', $outputdir . '/primary.dump', - '--no-sync', '-p', $node_primary->port + '--no-sync', '-p', $node_primary->port, + '--no-unlogged-table-data' # if unlogged, standby has schema only ], 'dump primary server'); command_ok( Attachments: [text/plain] stream-regress-unlogged-v1.patch (976B, ../../[email protected]/2-stream-regress-unlogged-v1.patch) download | inline diff: Author: Noah Misch <[email protected]> Commit: Noah Misch <[email protected]> Use --no-unlogged-table-data in t/027_stream_regress.pl. This removes the need to drop unlogged relations in the src/test/regress suite, like commit dec8ad367e46180f826d5b6dc820fbecba1b71d2 did. Reviewed by FIXME. Discussion: https://postgr.es/m/[email protected] diff --git a/src/test/recovery/t/027_stream_regress.pl b/src/test/recovery/t/027_stream_regress.pl index fdb4ea0..7982ac0 100644 --- a/src/test/recovery/t/027_stream_regress.pl +++ b/src/test/recovery/t/027_stream_regress.pl @@ -100,7 +100,8 @@ $node_primary->wait_for_catchup($node_standby_1, 'replay', command_ok( [ 'pg_dumpall', '-f', $outputdir . '/primary.dump', - '--no-sync', '-p', $node_primary->port + '--no-sync', '-p', $node_primary->port, + '--no-unlogged-table-data' # if unlogged, standby has schema only ], 'dump primary server'); command_ok( ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-05-22 04:24 Thomas Munro <[email protected]> parent: Noah Misch <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Thomas Munro @ 2022-05-22 04:24 UTC (permalink / raw) To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]> On Sat, May 21, 2022 at 6:15 PM Noah Misch <[email protected]> wrote: > On Mon, Apr 25, 2022 at 10:05:08AM -0400, Tom Lane wrote: > > Alvaro Herrera <[email protected]> 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 that the > > > regression database does not have any UNLOGGED relations. Maybe that's > > > something we need to cater for, eventually, but for now dropping the > > > table suffices. I have pushed that. > > > > It does seem like the onus should be on 027_stream_regress.pl to > > deal with that, rather than restricting what the core tests can > > leave behind. > > Yeah. Using "pg_dumpall --no-unlogged-table-data", as attached, suffices. 'pg_dumpall', '-f', $outputdir . '/primary.dump', - '--no-sync', '-p', $node_primary->port + '--no-sync', '-p', $node_primary->port, + '--no-unlogged-table-data' # if unlogged, standby has schema only LGTM, except for the stray extra whitespace. I tested by reverting dec8ad36 locally, at which point "gmake check" still passed but "gmake -C src/test/recovery/ check PROVE_TESTS=t/027_stream_regress.pl PROVE_FLAGS=-v" failed, and then your change fixed that. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-05-22 04:54 Noah Misch <[email protected]> parent: Thomas Munro <[email protected]> 0 siblings, 0 replies; 15+ messages in thread From: Noah Misch @ 2022-05-22 04:54 UTC (permalink / raw) To: Thomas Munro <[email protected]>; +Cc: Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]> On Sun, May 22, 2022 at 04:24:16PM +1200, Thomas Munro wrote: > On Sat, May 21, 2022 at 6:15 PM Noah Misch <[email protected]> wrote: > > On Mon, Apr 25, 2022 at 10:05:08AM -0400, Tom Lane wrote: > > > Alvaro Herrera <[email protected]> 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 that the > > > > regression database does not have any UNLOGGED relations. Maybe that's > > > > something we need to cater for, eventually, but for now dropping the > > > > table suffices. I have pushed that. > > > > > > It does seem like the onus should be on 027_stream_regress.pl to > > > deal with that, rather than restricting what the core tests can > > > leave behind. > > > > Yeah. Using "pg_dumpall --no-unlogged-table-data", as attached, suffices. > > 'pg_dumpall', '-f', $outputdir . '/primary.dump', > - '--no-sync', '-p', $node_primary->port > + '--no-sync', '-p', $node_primary->port, > + '--no-unlogged-table-data' # if unlogged, standby > has schema only > > LGTM, except for the stray extra whitespace. perltidy contributes the prior-line whitespace change. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-12 08:47 [email protected] parent: Amul Sul <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: [email protected] @ 2022-09-12 08:47 UTC (permalink / raw) To: [email protected] 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 rootOfPostingTree[BLCKSZ / (sizeof(IndexTupleData) + sizeof(ItemId))]; uint32 nRoot; - + Assert(0); gvs.tmpCxt = AllocSetContextCreate(CurrentMemoryContext, "Gin vacuum temporary context", ALLOCSET_DEFAULT_SIZES); I have check-world passed successfully. Amul Sul писал 2021-11-29 12:04: > 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. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-14 06:46 [email protected] parent: [email protected] 0 siblings, 1 reply; 15+ messages in thread From: [email protected] @ 2022-09-14 06:46 UTC (permalink / raw) To: [email protected]; Amul Sul <[email protected]> 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 [email protected] писал 2022-09-12 15:47: > 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 rootOfPostingTree[BLCKSZ / (sizeof(IndexTupleData) > + sizeof(ItemId))]; > uint32 nRoot; > - > + Assert(0); > gvs.tmpCxt = AllocSetContextCreate(CurrentMemoryContext, > > "Gin vacuum temporary context", > > ALLOCSET_DEFAULT_SIZES); > I have check-world passed successfully. > > Amul Sul писал 2021-11-29 12:04: >> 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. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-14 07:28 Amul Sul <[email protected]> parent: [email protected] 0 siblings, 1 reply; 15+ messages in thread From: Amul Sul @ 2022-09-14 07:28 UTC (permalink / raw) To: [email protected]; +Cc: PostgreSQL Hackers <[email protected]> On Wed, Sep 14, 2022 at 12:16 PM <[email protected]> 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 ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-21 07:10 [email protected] parent: Amul Sul <[email protected]> 0 siblings, 2 replies; 15+ messages in thread From: [email protected] @ 2022-09-21 07:10 UTC (permalink / raw) To: Amul Sul <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 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 to different results of the heap_prune_satisfies_vacuum() check inside heap_page_prune()). But as the make checks mostly (including the buildfarm testing) performed with -O2/-Og, it looks like that after 4fb5c794e5 we have lost the coverage provided by the 4c51a2d1e4. Amul Sul писал 2022-09-14 14:28: > On Wed, Sep 14, 2022 at 12:16 PM <[email protected]> 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 ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-21 11:58 Alvaro Herrera <[email protected]> parent: [email protected] 1 sibling, 0 replies; 15+ messages in thread From: Alvaro Herrera @ 2022-09-21 11:58 UTC (permalink / raw) To: [email protected]; +Cc: Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; [email protected]; [email protected] On 2022-Sep-21, [email protected] 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 we build with -O2 or -Og that function is not reached (due to different > results of the heap_prune_satisfies_vacuum() check inside > heap_page_prune()). > But as the make checks mostly (including the buildfarm testing) performed > with -O2/-Og, it looks like that after 4fb5c794e5 we have lost the coverage > provided by the 4c51a2d1e4. Hmm, so if we merely revert the change to gin.sql then we still won't get the coverage back? I was thinking that a simple change would be to revert the change from temp to unlogged for that table, and create another unlogged table; but maybe that's not enough. Do we need a better test for GIN vacuuming that works regardless of the optimization level? -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Investigación es lo que hago cuando no sé lo que estoy haciendo" (Wernher von Braun) ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-24 17:20 Noah Misch <[email protected]> parent: [email protected] 1 sibling, 1 reply; 15+ messages in thread From: Noah Misch @ 2022-09-24 17:20 UTC (permalink / raw) To: [email protected]; +Cc: Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; [email protected]; [email protected] On Wed, Sep 21, 2022 at 02:10:42PM +0700, [email protected] 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 we build with -O2 or -Og that function is not reached (due to different > results of the heap_prune_satisfies_vacuum() check inside > heap_page_prune()). With "make check MAX_CONNECTIONS=1", does that difference between -O0 and -O2 still appear? Compiler optimization shouldn't consistently change pruning decisions. It could change pruning decisions probabilistically, by changing which parallel actions overlap. If the difference disappears under MAX_CONNECTIONS=1, the system is likely fine. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-25 13:49 [email protected] parent: Noah Misch <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: [email protected] @ 2022-09-25 13:49 UTC (permalink / raw) To: Noah Misch <[email protected]>; +Cc: Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; [email protected]; [email protected] 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&dt=2022-09-25%2001%3A01%3A1... https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tayra&dt=2022-09-24%2020%3A40%3A00 the ginbulkdelete() most probably is not tested. In other words, it seems that we've just lost the effect of 4c51a2d1e4: Add a test case that exercises vacuum's deletion of empty GIN posting pages. Since this is a temp table, it should now work reliably to delete a bunch of rows and immediately VACUUM. Before the preceding commit, this would not have had the desired effect, at least not in parallel regression tests. Noah Misch писал 2022-09-25 00:20: > On Wed, Sep 21, 2022 at 02:10:42PM +0700, [email protected] > 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 we build with -O2 or -Og that function is not reached (due to >> different >> results of the heap_prune_satisfies_vacuum() check inside >> heap_page_prune()). > > With "make check MAX_CONNECTIONS=1", does that difference between -O0 > and -O2 > still appear? Compiler optimization shouldn't consistently change > pruning > decisions. It could change pruning decisions probabilistically, by > changing > which parallel actions overlap. If the difference disappears under > MAX_CONNECTIONS=1, the system is likely fine. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-25 14:49 Tom Lane <[email protected]> parent: [email protected] 0 siblings, 1 reply; 15+ messages in thread From: Tom Lane @ 2022-09-25 14:49 UTC (permalink / raw) To: [email protected]; +Cc: Noah Misch <[email protected]>; Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; [email protected] [email protected] 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&dt=2022-09-25%2001%3A01%3A1... > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tayra&dt=2022-09-24%2020%3A40%3A00 > the ginbulkdelete() most probably is not tested. > In other words, it seems that we've just lost the effect of 4c51a2d1e4: > Add a test case that exercises vacuum's deletion of empty GIN > posting pages. 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 So it seems clear that 4fb5c794e5 made at least some coverage worse not better. I think we'd better rejigger it to add some new indexes not repurpose old ones. regards, tom lane ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-25 15:51 Tom Lane <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Tom Lane @ 2022-09-25 15:51 UTC (permalink / raw) To: [email protected]; +Cc: Noah Misch <[email protected]>; Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; [email protected] 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 week. So the coverage is probabilistic, which squares with this discussion and with some tests I just did locally. That's not good. I shudder to imagine how much time somebody might waste trying to locate a bug in this area, if a test failure appears and disappears regardless of code changes they make while chasing it. 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?). Looks like dec8ad367 could be reverted as well, in view of 2f2e24d90. regards, tom lane ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-25 15:57 Alvaro Herrera <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Alvaro Herrera @ 2022-09-25 15:57 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: [email protected]; Noah Misch <[email protected]>; Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected] 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. Completely agreed. > 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 want. > Looks like dec8ad367 could be reverted as well, in view of 2f2e24d90. Yeah, sounds good. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: tweak to a few index tests to hits ambuildempty() routine. @ 2022-09-25 16:19 Tom Lane <[email protected]> parent: Alvaro Herrera <[email protected]> 0 siblings, 0 replies; 15+ messages in thread From: Tom Lane @ 2022-09-25 16:19 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: [email protected]; Noah Misch <[email protected]>; Amul Sul <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected] Alvaro Herrera <[email protected]> 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 want. On it now. regards, tom lane ^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2022-09-25 16:19 UTC | newest] Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-11-29 05:04 tweak to a few index tests to hits ambuildempty() routine. Amul Sul <[email protected]> 2022-09-12 08:47 ` [email protected] 2022-09-14 06:46 ` [email protected] 2022-09-14 07:28 ` Amul Sul <[email protected]> 2022-09-21 07:10 ` [email protected] 2022-09-21 11:58 ` Alvaro Herrera <[email protected]> 2022-09-24 17:20 ` Noah Misch <[email protected]> 2022-09-25 13:49 ` [email protected] 2022-09-25 14:49 ` Tom Lane <[email protected]> 2022-09-25 15:51 ` Tom Lane <[email protected]> 2022-09-25 15:57 ` Alvaro Herrera <[email protected]> 2022-09-25 16:19 ` Tom Lane <[email protected]> 2022-05-21 06:15 Re: tweak to a few index tests to hits ambuildempty() routine. Noah Misch <[email protected]> 2022-05-22 04:24 ` Thomas Munro <[email protected]> 2022-05-22 04:54 ` Noah Misch <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox