| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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: | 2022-03-11 03:52:24 |
| Message-ID: | CAH2-WzmoR6YdhV+pk2vjfj9mRUoTkhPKTmmjvXqCnmgU442Zug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Mar 10, 2022 at 7:46 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I'm not talking about just moving the vistest acquisition, but also
> vacuum_set_xid_limits(). Which obviously *does* benefit from delaying as long
> as possible.
That sounds hard, or at least a lot of work given the benefits.
As the patch points out, we are required to establish rel_pages after
we have established OldestXmin. We *also* use rel_pages to determine
the size of the dead_items array -- we don't want to allocate space
that couldn't possibly be used (i.e. a dead_items array with room for
more than `MaxHeapTuplesPerPage * rel_pages` dead items in total).
In short, it will be necessary to break that dependency, somehow.
Which is possibly, certainly, but still quite messy.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-03-11 04:08:08 | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum |
| Previous Message | Andres Freund | 2022-03-11 03:46:32 | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum |