maintenance_work_mem = 64kB doesn't work for vacuum
От | Masahiko Sawada |
---|---|
Тема | maintenance_work_mem = 64kB doesn't work for vacuum |
Дата | |
Msg-id | CAD21AoCEAmbkkXSKbj4dB+5pJDRL4ZHxrCiLBgES_g_g8mVi1Q@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: maintenance_work_mem = 64kB doesn't work for vacuum
Re: maintenance_work_mem = 64kB doesn't work for vacuum |
Список | pgsql-hackers |
Hi, Commit bbf668d66fbf6 (back-patched to v17) lowered the minimum maintenance_work_mem to 64kB, but it doesn't work for parallel vacuum cases since the minimum dsa segment size (DSA_MIN_SEGMENT_SIZE) is 256kB. As soon as the radix tree allocates its control object and the root node, the memory usage exceeds the maintenance_work_mem limit and vacuum ends up with the following assertion: TRAP: failed Assert("vacrel->lpdead_item_pages > 0"), File: "vacuumlazy.c", Line: 2447, PID: 3208575 On build without --enable-cassert, vacuum never ends. I've tried to lower DSA_MIN_SEGMENT_SIZE to 64kB but no luck. Investigating it further, dsa creates a 64kB superblock for each size class and when creating a new shared radix tree we need to create two superblocks: one for the radix tree control data (64 bytes) and another one for the root node (40 bytes). Also, each superblock requires a span data, which uses 1 page (4096kB). Therefore, we need at least 136kB for a shared radix tree even when it's empty. A simple fix is to bump the minimum maintenance_work_mem to 256kB. We would break the compatibility for backbranch (i.e. v17) but I guess it's unlikely that existing v17 users are using less than 1MB maintenance_work_mem (the release note doesn't mention the fact that we lowered the minimum value). Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: