| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum |
| Date: | 2021-11-19 00:36:23 |
| Message-ID: | 20211119003623.d3jusiytzjqwb62p@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2021-11-17 23:19:41 -0800, Andres Freund wrote:
> Not sure if it's worth it, but I think this can be made into a reliably
> isolationtest by causing a tables index to locked exclusively, blocking
> vac_open_indexes(), which can then reliably schedule a new relcache inval,
> which in turn can compute a new RecentXmin. Might be too fragile to be worth
> it.
Attached is such an isolationtest. In an unmodified HEAD it ends up with
step s1_select_1:
SET LOCAL enable_seqscan = false;
SELECT ctid, /*xmin, xmax, */ id FROM many_updates WHERE id = 1;
RESET enable_seqscan;
ctid |id
-----+--
(0,3)|17
(1 row)
without amcheck detecting corruption at that point:(.
It's clearly not yet something we could consider committable, but I think it
might be a useful basis for such a test.
Greetings,
Andres Freund
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-wip-test-heap_prune_page-bug-recently-dead-dead-i.patch | text/x-diff | 23.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2021-11-19 02:55:08 | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum |
| Previous Message | Dmitry Koval | 2021-11-18 18:48:55 | Re: BUG #17288: PSQL bug with COPY command (Windows) |