From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sqlsmith crash incremental sort |
Date: | 2020-04-13 00:41:54 |
Message-ID: | 20200413004154.GP2228@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 13, 2020 at 02:09:43AM +0200, Tomas Vondra wrote:
> Justin, can you try if this resolves the crashes or if there's something
> else going on?
With your patch, this no longer crashes:
|explain SELECT * FROM information_schema.transforms AS ref_1 RIGHT JOIN (SELECT 1 FROM pg_catalog.pg_namespace TABLESAMPLE SYSTEM (7.2))AS sample_2 ON (ref_1.specific_name is NULL);
..and sqlsmith survived 20min, which is a good sign.
pg_ctl -c -D pgsql13.dat start -o '-c port=1234 -c log_min_messages=fatal'
sqlsmith --target='host=/tmp port=1234 dbname=postgres' --verbose
Previously, I changed find_base_rel()'s Assert to an if(){elog}, so I know from
another 12 sqlsmith-hours that there's no other crash occuring frequently.
(I hadn't used sqlsmith before this weekend, and was excited when I first saw
that it'd crashed overnight, and very surprised (after enabling core dumps) to
see that it crashed within ~10min.)
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-04-13 00:56:02 | Re: pg_basebackup, manifests and backends older than ~12 |
Previous Message | Andres Freund | 2020-04-13 00:27:50 | Re: where should I stick that backup? |