Re: Possible fails in pg_stat_statements test
От | Anton A. Melnikov |
---|---|
Тема | Re: Possible fails in pg_stat_statements test |
Дата | |
Msg-id | c8420d1b-15cd-bda6-6914-ad004b46fab9@inbox.ru обсуждение исходный текст |
Ответ на | Re: Possible fails in pg_stat_statements test (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Possible fails in pg_stat_statements test
|
Список | pgsql-hackers |
Hello! On 30.03.2022 22:36, Robert Haas wrote: > I don't think that the idea of "extra" WAL records is very principled. > It's pretty vague what "extra" means, and your definition seems to be > basically "whatever would be needed to make this test case pass." I > think the problem is basically with the test cases's idea that # of > WAL records and # of table rows ought to be equal. I think that's just > false. In general, we'd also have to worry about index insertions, > which would provoke variable numbers of WAL records depending on > whether they cause a page split. And we'd have to worry about TOAST > table insertions, which could produce different numbers of records > depending on the size of the data, the configured block size and TOAST > threshold, and whether the TOAST table index incurs a page split. Thank you very much for this information. I really didn't take it into account. > If it's true that this test case sometimes randomly fails, then we > ought to fix that somehow, maybe by just removing this particular > check from the test case, or changing it to >=, or something like > that. But I don't think adding a new counter is the right idea. Indeed. Then there is a very simple solution for this particular case as wal_records counter may only sometime becomes greater but never less. The corresponding patch is attached. With best regards, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: