From: | Mikhail Gribkov <youzhick(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Avoid race condition for event_triggers regress test |
Date: | 2023-10-18 19:36:58 |
Message-ID: | CAMEv5_sS5G7K1PCV2oBx5+1NF1ZneJ6C5Z_xV_SWsZMukdFZiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
After committing the on-login trigger
(e83d1b0c40ccda8955f1245087f0697652c4df86) the event_trigger regress test
became sensible to any other parallel tests, not only DDL. Thus it should
be placed in a separate parallel schedule group.
The current problem is that a race condition may occur on some systems,
when oidjoins test starts a moment later than normally and affects logins
count for on-login trigger test. The problem is quite a rare one and I only
faced it once. But rare or not - the problem is a problem and it should be
addressed.
Such race condition can be simulated by adding "select pg_sleep(2);" and
"\c" at the very beginning of oidjoins.sql and adding "select pg_sleep(5);"
after creation of the login trigger in event_trigger.sql.
The resulting symptoms are quite recognizable: regression.diffs file will
contain unexpected welcome message for oidjoins test and unexpectedly
increased result of "SELECT COUNT(*) FROM user_logins;" for event_triggers
test. (These are accompanied with the expected responses to the newly added
commands of course)
To get rid of the unexpected results the oidjoins and event_triggers tests
should be splitted into separate paralell schedule groups. This is exactly
what the proposed (attached) patch is doing.
What do you think?
--
best regards,
Mikhail A. Gribkov
e-mail: youzhick(at)gmail(dot)com
Attachment | Content-Type | Size |
---|---|---|
v001_avoid_race_condition_for_event_trigger_test.patch | application/octet-stream | 943 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2023-10-18 19:53:30 | Re: Parent/child context relation in pg_get_backend_memory_contexts() |
Previous Message | Thomas Munro | 2023-10-18 19:18:01 | Re: Guiding principle for dropping LLVM versions? |