Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS
Дата
Msg-id CAGRY4nzepco2XsyExXHq=CgVBD=CRrW-LOQr6=ymEVZWr3-xLQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Список pgsql-hackers


On Mon, 30 Nov 2020, 20:38 Anastasia Lubennikova, <a.lubennikova@postgrespro.ru> wrote:
On 27.10.2020 11:34, Peter Eisentraut wrote:
> On 2020-09-25 09:40, Craig Ringer wrote:
>> While working on extensions I've often wanted to enable cache
>> clobbering for a targeted piece of code, without paying the price of
>> running it for all backends during postgres startup and any initial
>> setup tasks that are required.
>>
>> So here's a patch that, when CLOBBER_CACHE_ALWAYS or
>> CLOBBER_CACHE_RECURSIVE are defined, adds a GUC named
>> clobber_cache_depth . It defaults to 1 for CLOBBER_CACHE_ALWAYS or 3
>> for CLOBBER_CACHE_RECURSIVE to match the existing compiled-in
>> behaviour. But with this change it's now possible to run Pg with
>> clobber_cache_depth=0 then set it to 1 only for targeted tests.
>>
>> clobber_cache_depth is treated as an unknown GUC if Pg was not built
>> with CLOBBER_CACHE_ALWAYS or CLOBBER_CACHE_RECURSIVE defined.
>
> I think it would be great if the cache clobber code is always compiled
> in (but turned off) when building with assertions.  The would reduce
> the number of hoops to jump through to actually use this locally and
> reduce the number of surprises from the build farm.
>
> For backward compatibility, you can arrange it so that the built-in
> default of clobber_cache_depth is 1 or 3 if CLOBBER_CACHE_ALWAYS or
> CLOBBER_CACHE_RECURSIVE are defined.
>

Status update for a commitfest entry.

This thread was inactive during the commitfest, so I am going to mark it
as "Returned with Feedback".
Craig, are you planning to continue working on it? The proposed idea is
great and it looks like the patch needs only a minor improvement.

Thanks.

I'll update it soon. 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Printing backtrace of postgres processes
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [POC] Fast COPY FROM command for the table with foreign partitions