Content-Type: multipart/mixed; boundary="------------Qfcm60Y0OsU0Ya3cZn4EkaRk"
Message-ID: <2615f158-b790-4176-11ad-9711e4fd56c7@enterprisedb.com>
Date: Thu, 20 Jan 2022 18:57:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: BUG #17372: Altering statistics during concurrent drop can lead
 to a server crash
Content-Language: en-US
To: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org,
 PG Bug reporting form <noreply@postgresql.org>
References: <17372-bf3b6e947e35ae77@postgresql.org>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <17372-bf3b6e947e35ae77@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/2615f158-b790-4176-11ad-9711e4fd56c7%40enterprisedb.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------Qfcm60Y0OsU0Ya3cZn4EkaRk
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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
--------------Qfcm60Y0OsU0Ya3cZn4EkaRk
Content-Type: text/x-patch; charset=UTF-8; name="alter-statistics-fix.patch"
Content-Disposition: attachment; filename="alter-statistics-fix.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2NvbW1hbmRzL3N0YXRzY21kcy5jIGIvc3JjL2Jh
Y2tlbmQvY29tbWFuZHMvc3RhdHNjbWRzLmMKaW5kZXggZWRjNGM0ODEwNDMuLjU5ZTUzMWI1
NWQ4IDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9jb21tYW5kcy9zdGF0c2NtZHMuYworKysg
Yi9zcmMvYmFja2VuZC9jb21tYW5kcy9zdGF0c2NtZHMuYwpAQCAtNjc3LDYgKzY3Nyw4IEBA
IEFsdGVyU3RhdGlzdGljcyhBbHRlclN0YXRzU3RtdCAqc3RtdCkKIAlyZWwgPSB0YWJsZV9v
cGVuKFN0YXRpc3RpY0V4dFJlbGF0aW9uSWQsIFJvd0V4Y2x1c2l2ZUxvY2spOwogCiAJb2xk
dHVwID0gU2VhcmNoU3lzQ2FjaGUxKFNUQVRFWFRPSUQsIE9iamVjdElkR2V0RGF0dW0oc3R4
b2lkKSk7CisJaWYgKCFIZWFwVHVwbGVJc1ZhbGlkKG9sZHR1cCkpCisJCWVsb2coRVJST1Is
ICJjYWNoZSBsb29rdXAgZmFpbGVkIGZvciBleHRlbmRlZCBzdGF0aXN0aWNzIG9iamVjdCAl
dSIsIHN0eG9pZCk7CiAKIAkvKiBNdXN0IGJlIG93bmVyIG9mIHRoZSBleGlzdGluZyBzdGF0
aXN0aWNzIG9iamVjdCAqLwogCWlmICghcGdfc3RhdGlzdGljc19vYmplY3Rfb3duZXJjaGVj
ayhzdHhvaWQsIEdldFVzZXJJZCgpKSkK
--------------Qfcm60Y0OsU0Ya3cZn4EkaRk--