Re: WAL usage calculation patch

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: WAL usage calculation patch
Дата
Msg-id 20200318171916.GA69354@nol
обсуждение исходный текст
Ответ на Re: WAL usage calculation patch  (Kirill Bychik <kirill.bychik@gmail.com>)
Ответы Re: WAL usage calculation patch  (Kirill Bychik <kirill.bychik@gmail.com>)
Re: WAL usage calculation patch  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
On Wed, Mar 18, 2020 at 09:02:58AM +0300, Kirill Bychik wrote:
>
> There is a higher-level Instrumentation API that can be used with
> INSTRUMENT_WAL flag to collect the wal usage information. I believe
> the instrumentation is widely used in the executor code, so it should
> not be a problem to colelct instrumentation information on autovacuum
> worker level.
>
> Just a recommendation/chat, though. I am happy with the way the data
> is collected now. If you commit this variant, please add a TODO to
> rework wal usage to common instr API.


The instrumentation is somewhat intended to be used with executor nodes, not
backend commands.  I don't see real technical reason that would prevent that,
but I prefer to keep things as-is for now, as it sound less controversial.
This is for the 3rd patch, which may not even be considered for this CF anyway.


> > > As for the tests, please get somebody else to review this. I strongly
> > > believe checking full page writes here could be a source of
> > > instability.
> >
> >
> > I'm also a little bit dubious about it.  The initial checkpoint should make
> > things stable (of course unless full_page_writes is disabled), and Cfbot also
> > seems happy about it.  At least keeping it for the temporary tables test
> > shouldn't be a problem.
>
> Temp tables should show zero FPI WAL records, true :)
>
> I have no objections to the patch.


I'm attaching a v5 with fp records only for temp tables, so there's no risk of
instability.  As I previously said I'm fine with your two patches, so unless
you have objections on the fpi test for temp tables or the documentation
changes, I believe those should be ready for committer.

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: type of some table storage params on doc
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: new polymorphic types - commontype and commontypearray