Skip to content

Conversation

Alena0704
Copy link
Collaborator

It turned out that vanilla regression tests failed using aqo_pg 14.patch in this version. This problem is related to running the Enable Query Id function in _PG_init(). We cannot remove the call to this function due to the launch of assert when query_id_enabled is disabled in query jumble. A similar function to enable query_id_enabled (enable query id) is used in pg_stat_statements, but the Makefile contains the addition of NO_INSTALL CHECK = 1 and does not run regression tests by default.
So, I have prepared changes for fix it.

@Alena0704 Alena0704 requested a review from danolivo October 26, 2022 07:53
Alena Rybakina added 2 commits October 26, 2022 11:07
It is necessary for avoiding output Query Identifier while vanille's test are running.

(Look at more in explain.c:612.
We can get fail condition if only query identifier is not null)

Where clause 'NOT LIKE '%Query Identifier%'' is throwed away due to being necessary any more.
This addition parameter is appeared if we set compute_query_id parameter with value as 'auto'.
Appearance of the parameter is checked in only gucs test.
Delete platform dependent lines containing Memory and
add order by command in feature_subspace test for statical result.

-- Check AQO addons to explain (the only stable data)
SELECT str FROM expln('
SELECT regexp_replace(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

А зачем здесь тебе таки показывать Query Identifier ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Видимо, проверяется, что он вообще выводится..

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Да, делала проверку на вывод Query Identifier. Показалось логичным оставить это только в gucs тесте.
Специально добавила установку параметра compute_query_id в 'auto'.
В других тестах не добавляла и убрала Query Identifier из-за его ненужности там.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Видимо, проверяется, что он вообще выводится..

Ну, это достаточно слабое объяснение. Query Identifier вообще ванильная штука, чего его проверять? Я бы скорее сказал, что проверяются другие параметры экплейна, AQO-специфичные. А для них Identifier не нужен

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Тогда здесь можно убрать, как это сделано в остальных тестах?

max_parallel_maintenance_workers = 1 # switch off parallel workers because of unsteadiness
aqo.wide_search = 'on'
aqo.wide_search = 'on'
compute_query_id = 'regress'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

А это никак не повлияет на другие тесты, выполняемые installcheck ? И почему?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

У нас сейчас есть schedule-файл с порядком выполнения тестов. Почему бы не устанавливать это значение в первом тесте и не сбрасывать в последнем?

Copy link

@MarinaPolyakova MarinaPolyakova Oct 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

А это никак не повлияет на другие тесты, выполняемые installcheck ? И почему?

compute_query_id = 'regress' => не выводить query id, даже если он посчитался. Вроде тогда мы и другие тесты не ломаем, и функциональность по факту тестируется?.. (если что-то упадет при подсчете, то это будет заметно?)

Copy link

@MarinaPolyakova MarinaPolyakova Oct 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

У нас сейчас есть schedule-файл с порядком выполнения тестов. Почему бы не устанавливать это значение в первом тесте и не сбрасывать в последнем?

Во-первых, compute_query_id = 'regress' в любом случае нужен, чтобы не сломался make installcheck в дереве исходников postgres с загруженным aqo. Как писала Алена, мы проверили, что pg_stat_statements от этого спасает только NO_INSTALLCHECK = 1 в contrib/pg_stat_statements/Makefile. aqo себе такого позволить не может.

Во-вторых, вроде каждый тест = отдельное соединение в psql? Т.е. переменная сбросится между тестами?..

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

У нас сейчас есть schedule-файл с порядком выполнения тестов. Почему бы не устанавливать это значение в первом тесте и не сбрасывать в последнем?

Не поможет. sheduller настроен на прогон aqo тестов и соответствующие настройки с параметрами, как понимаю, применяются к ним. У нас изначально возникла проблема с ванильными тестами.
Или ты говоришь про sheduller ванильных тестов? Но тогда, это пойдут изменения в ванильный код, чего мы хотим избежать

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

А это никак не повлияет на другие тесты, выполняемые installcheck ? И почему?

Ты имеешь в виду другие расширения, которые работают одновременно с AQO и данная настройка их коснется или про тесты в AQO? Или вообще про другое? Можешь уточнить вопрос, пожалуйста.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

А это никак не повлияет на другие тесты, выполняемые installcheck ? И почему?

compute_query_id = 'regress' => не выводить query id, даже если он посчитался. Вроде тогда мы и другие тесты не ломаем, и функциональность по факту тестируется?.. (если что-то упадет при подсчете, то это будет заметно?)

Ну так и сделайте это глобальным параметром своих тестов, если возможно, зачем это в открытое расширение складывать?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

У нас сейчас есть schedule-файл с порядком выполнения тестов. Почему бы не устанавливать это значение в первом тесте и не сбрасывать в последнем?

Во-первых, compute_query_id = 'regress' в любом случае нужен, чтобы не сломался make installcheck в дереве исходников postgres с загруженным aqo. Как писала Алена, мы проверили, что pg_stat_statements от этого спасает только NO_INSTALL CHECK = 1 в contrib/pg_stat_statements/Makefile. aqo себе такого позволить не может.
AQO построен так же, как и pg_stat_statements. По крайней мере гитхабовская версия проекта желательно должна выглядеть традиционно. А патчи для различных энтерпрайзных версий можно и внутри хранить ...

Во-вторых, вроде каждый тест = отдельное соединение в psql? Т.е. переменная сбросится между тестами?..
ALTER SYSTEM + pg_reload_conf() там не срабатывает?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ну так и сделайте это глобальным параметром своих тестов, если возможно, зачем это в открытое расширение складывать?

Потому что тесты падают только с загруженным расширением (в данном случае - aqo). Без вас все норм.

Copy link

@MarinaPolyakova MarinaPolyakova Oct 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ALTER SYSTEM + pg_reload_conf() там не срабатывает?

  1. pg_reload_conf вроде только отправляет сигнал postmaster? В смысле, надеюсь, в тестах не будет гонок..
  2. Если запустить паралельный installcheck-world (make -jN installcheck-world), с помощью ALTER SYSTEM вы повлияете на другие тесты?..

@Alena0704 Alena0704 merged commit 961bdcf into stable14 Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants