| 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 18:42:30 |
| Message-ID: | CAH2-Wz=CfrHkcy50syYpgB-bshh=3XN5MQQRqeUAppqCFrC9cQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Mar 10, 2022 at 7:13 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Large allocation can take a bit. Especially dead_item_alloc() sneakily
> initializes parallelism (which is darn ugly).
Attached v3 revision of the patch makes this a bit clearer.
The patch now moves the pg_class updates for indexes from the end of
lazy_scan_heap() to its heap_vacuum_rel() caller, at the point just
after lazy_scan_heap() returns. This seems logical to me because it
makes all pg_class updates take place inside heap_vacuum_rel(). It
also means that we pretty start parallel mode right at the beginning
of lazy_scan_heap(), and end it right at the end -- which also seems
like a small improvement.
And so we no longer end parallel mode in order to be able to safely
update pg_class for indexes. Rather, we end parallel mode because
processing by lazy_scan_heap() as a whole completed.
--
Peter Geoghegan
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0002-vacuumlazy.c-Rename-nblocks-to-rel_pages.patch | application/octet-stream | 4.2 KB |
| v3-0001-vacuumlazy.c-Document-vistest-and-OldestXmin.patch | application/octet-stream | 14.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-03-11 19:53:12 | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |
| Previous Message | Tom Lane | 2022-03-11 18:29:05 | Re: BUG #17409: Unable to alter data type of clustered column which is referenced by foreign key |