agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Initialize bs_reltuples in parallel GIN builds 3+ messages / 1 participants [nested] [flat]
* pgsql: Initialize bs_reltuples in parallel GIN builds @ 2026-07-30 13:10 Tomas Vondra <tomas.vondra@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Tomas Vondra @ 2026-07-30 13:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Initialize bs_reltuples in parallel GIN builds Index builds update pg_class.reltuples for the table. In parallel GIN builds, workers track the number of processed rows, and report it to the leader, who then updates the pg_class with a total. However, gin_parallel_build_main failed to initialize the bs_reltuples field, leaving it set to whatever happens to be on the stack (which may be bogus values like Infinity or NaN, or just impossibly high values). If such values get reported to the leader and stored in pg_class, that can have serious consequences. The pg_class.reltuples field is used to decide when a table is due for autovacuum or autoanalyze, and if it happens to be set to a bogus value, that may never happen. The field is also used by the optimizer when calculating costs. Fixed by initializing bs_reltuples together with the rest of the build state. The bs_numtuples was initialized later, but it seems cleaner to just initialize all the fields at once. After a bogus value gets persisted in pg_class, affected systems are unlikely to self-heal. That would require an ANALYZE, but preventing that is one of the consequences. We have considered forcing autoanalyze in these cases, but there's not a good way to reliably identify bogus values (except for a small minority like Infitiny/NaN). A manual ANALYZE on (possibly) affected tables is the only solution. Backpatch to 18, where parallel GIN builds were introduced. Reported-by: Jan Nidzwetzki <jan@planetscale.com> Discussion: https://postgr.es/m/518BA772-8026-412A-AA8F-A7FE4C6B3717@planetscale.com Backpatch-through: 18 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/1232f7a08365619a720dd4c9f35a8fb299b5ea08 Modified Files -------------- src/backend/access/gin/gininsert.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Initialize bs_reltuples in parallel GIN builds @ 2026-07-30 13:10 Tomas Vondra <tomas.vondra@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Tomas Vondra @ 2026-07-30 13:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Initialize bs_reltuples in parallel GIN builds Index builds update pg_class.reltuples for the table. In parallel GIN builds, workers track the number of processed rows, and report it to the leader, who then updates the pg_class with a total. However, gin_parallel_build_main failed to initialize the bs_reltuples field, leaving it set to whatever happens to be on the stack (which may be bogus values like Infinity or NaN, or just impossibly high values). If such values get reported to the leader and stored in pg_class, that can have serious consequences. The pg_class.reltuples field is used to decide when a table is due for autovacuum or autoanalyze, and if it happens to be set to a bogus value, that may never happen. The field is also used by the optimizer when calculating costs. Fixed by initializing bs_reltuples together with the rest of the build state. The bs_numtuples was initialized later, but it seems cleaner to just initialize all the fields at once. After a bogus value gets persisted in pg_class, affected systems are unlikely to self-heal. That would require an ANALYZE, but preventing that is one of the consequences. We have considered forcing autoanalyze in these cases, but there's not a good way to reliably identify bogus values (except for a small minority like Infitiny/NaN). A manual ANALYZE on (possibly) affected tables is the only solution. Backpatch to 18, where parallel GIN builds were introduced. Reported-by: Jan Nidzwetzki <jan@planetscale.com> Discussion: https://postgr.es/m/518BA772-8026-412A-AA8F-A7FE4C6B3717@planetscale.com Backpatch-through: 18 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5707d7517fa893f6d36b0e4a1173ee71699ada48 Modified Files -------------- src/backend/access/gin/gininsert.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Initialize bs_reltuples in parallel GIN builds @ 2026-07-30 13:10 Tomas Vondra <tomas.vondra@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Tomas Vondra @ 2026-07-30 13:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Initialize bs_reltuples in parallel GIN builds Index builds update pg_class.reltuples for the table. In parallel GIN builds, workers track the number of processed rows, and report it to the leader, who then updates the pg_class with a total. However, gin_parallel_build_main failed to initialize the bs_reltuples field, leaving it set to whatever happens to be on the stack (which may be bogus values like Infinity or NaN, or just impossibly high values). If such values get reported to the leader and stored in pg_class, that can have serious consequences. The pg_class.reltuples field is used to decide when a table is due for autovacuum or autoanalyze, and if it happens to be set to a bogus value, that may never happen. The field is also used by the optimizer when calculating costs. Fixed by initializing bs_reltuples together with the rest of the build state. The bs_numtuples was initialized later, but it seems cleaner to just initialize all the fields at once. After a bogus value gets persisted in pg_class, affected systems are unlikely to self-heal. That would require an ANALYZE, but preventing that is one of the consequences. We have considered forcing autoanalyze in these cases, but there's not a good way to reliably identify bogus values (except for a small minority like Infitiny/NaN). A manual ANALYZE on (possibly) affected tables is the only solution. Backpatch to 18, where parallel GIN builds were introduced. Reported-by: Jan Nidzwetzki <jan@planetscale.com> Discussion: https://postgr.es/m/518BA772-8026-412A-AA8F-A7FE4C6B3717@planetscale.com Backpatch-through: 18 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d4420a97206cad5bcf63405062db5b4ebaa7f2b1 Modified Files -------------- src/backend/access/gin/gininsert.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-07-30 13:10 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-30 13:10 pgsql: Initialize bs_reltuples in parallel GIN builds Tomas Vondra <tomas.vondra@postgresql.org> 2026-07-30 13:10 pgsql: Initialize bs_reltuples in parallel GIN builds Tomas Vondra <tomas.vondra@postgresql.org> 2026-07-30 13:10 pgsql: Initialize bs_reltuples in parallel GIN builds Tomas Vondra <tomas.vondra@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox