From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, PG Bug reporting form <noreply@postgresql.org>
Subject: Re: BUG #17372: Altering statistics during concurrent drop can lead to a server crash
Date: Thu, 20 Jan 2022 18:57:32 +0100
Message-ID: <2615f158-b790-4176-11ad-9711e4fd56c7@enterprisedb.com> (raw)
In-Reply-To: <17372-bf3b6e947e35ae77@postgresql.org>
References: <17372-bf3b6e947e35ae77@postgresql.org>
On 1/20/22 05:00, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 17372
> Logged by: Alexander Lakhin
> Email address: exclusion@gmail.com
> PostgreSQL version: 14.1
> Operating system: Ubuntu 20.04
> Description:
>
> The following script (based on the stats_ext test):
> psql -c "CREATE TABLE ab1 (a INTEGER, b INTEGER, c INTEGER);"
> for i in `seq 100`; do
> echo "iteration $i"
> ( { for n in `seq 20`; do echo "CREATE STATISTICS ab1_a_b_stats ON a, b FROM
> ab1; DROP STATISTICS ab1_a_b_stats;"; done } | psql ) >psql1.log 2>&1 &
> ( { for n in `seq 20`; do echo "ALTER STATISTICS ab1_a_b_stats SET
> STATISTICS -1;"; done } | psql ) >psql2.log 2>&1 &
>
> wait
> sleep 2
> coredumpctl --no-pager && break
> done
>
Thanks for the report - I've reproduced it using your script (I had to
add a short wait before the syscache lookup). The issue is fairly
simple, we never check we actually found a tuple in the syscache, i.e.
there's no HeapTupleIsValid() call. We check the OID earlier, but the
tuple may have disappeared since then.
IMO the usual "cache lookup failed" error that we throw in other places
in similar cases is good enough. We already fail with other errors
(tuple concurrently updated/deleted) here.
Patch attached.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
[text/x-patch] alter-statistics-fix.patch (618B, ../2615f158-b790-4176-11ad-9711e4fd56c7@enterprisedb.com/2-alter-statistics-fix.patch)
download | inline diff:diff --git a/src/backend/commands/statscmds.c b/src/backend/commands/statscmds.cindex edc4c481043..59e531b55d8 100644--- a/src/backend/commands/statscmds.c+++ b/src/backend/commands/statscmds.c@@ -677,6 +677,8 @@ AlterStatistics(AlterStatsStmt *stmt)
rel = table_open(StatisticExtRelationId, RowExclusiveLock);
oldtup = SearchSysCache1(STATEXTOID, ObjectIdGetDatum(stxoid));
+ if (!HeapTupleIsValid(oldtup))+ elog(ERROR, "cache lookup failed for extended statistics object %u", stxoid);
/* Must be owner of the existing statistics object */
if (!pg_statistics_object_ownercheck(stxoid, GetUserId()))
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tomas.vondra@enterprisedb.com, noreply@postgresql.org
Subject: Re: BUG #17372: Altering statistics during concurrent drop can lead to a server crash
In-Reply-To: <2615f158-b790-4176-11ad-9711e4fd56c7@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox