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%3A13
https:
Hello hackers,
On branch REL_15_STABLE the following query: SELECT
JSON_SERIALIZE('{"a":1}' RETURNING jsonb);
produces SIGSEGV for me:
#0 getJsonbOffset (index=39920251, jc=0x563cc5601d5c) at
jsonb_util.c:148
148 offset += JBE_OFFLENFLD(jc->children[i]);
(gdb) bt
#0 getJ
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 r
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 by
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 t
