From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie>, Masahiro(dot)Ikeda(at)nttdata(dot)com |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Masao(dot)Fujii(at)nttdata(dot)com |
Subject: | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Date: | 2024-09-07 15:27:05 |
Message-ID: | b05aa7ac-ae3a-49e1-a9da-22594bed3379@vondra.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I started looking at this patch today. The first thing I usually do for
new patches is a stress test, so I did a simple script that generates
random table and runs a random query with IN() clause with various
configs (parallel query, index-only scans, ...). And it got stuck on a
parallel query pretty quick.
I've seen a bunch of those cases, so it's not a particularly unlikely
issue. The backtraces look pretty much the same in all cases - the
processes are stuck either waiting on the conditional variable in
_bt_parallel_seize, or trying to send data in shm_mq_send_bytes.
Attached is the script I use for stress testing (pretty dumb, just a
bunch of loops generating tables + queries), and backtraces for two
lockups (one is EXPLAIN ANALYZE, but otherwise exactly the same).
I haven't investigated why this is happening, but I wonder if this might
be similar to the parallel hashjoin issues, with trying to send data,
but the receiver being unable to proceed and effectively working on the
sender. But that's just a wild guess.
regards
--
Tomas Vondra
Attachment | Content-Type | Size |
---|---|---|
lockup2.log | text/x-log | 17.4 KB |
lockup.log | text/x-log | 14.4 KB |
run.sh | application/x-shellscript | 8.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2024-09-07 18:05:00 | Re: PostgreSQL 17 release announcement draft |
Previous Message | Marcos Pegoraro | 2024-09-07 14:16:20 | Re: Detailed release notes |