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:
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
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
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
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
