postgres: alias insertion deadlock#1891
Conversation
b8d0c0b to
da65def
Compare
da65def to
a43e074
Compare
136e223 to
5928a1b
Compare
|
This appears to stop the deadlocks but causes the time to insert to increase considerably. Since we are inserting the aliases and namespaces outside of the transaction (so IIUC deadlocking is not an issue), would it be possible to collect all the aliases to be inserted using the dedupe maps that already exist and fire two bulk statements for the alias and the namespace? |
|
I'll take a look and try structuring it that way. |
96286f2 to
25bd69e
Compare
020f257 to
428280d
Compare
jvdm
left a comment
There was a problem hiding this comment.
Can we pull TestConcurrentUpdateVulnerabilities from #1934 which seems to test the deadlock?
Also, looks like this does not have the self alias fields on the test vulns in TestGetLatestVulnerabilities that #1934 added. Without the self fields, bulkLinkSelf is never exercised: no self set, vsHashKinds stays empty and the bulkLinkSelf statement never runs.
|
I removed that test because it didn't work; I could never get it to trip. The other changes to the tests were unintentional, I'll pull those back. |
This fixes a transaction conflict where concurrent updaters could attempt to insert the same alias namespaces and cause the entire update to abort. Signed-off-by: Hank Donnay <hdonnay@redhat.com> Change-Id: I4f7f613f17e47c7cbcff82fbbb7674a06a6a6964
Replace the per-vulnerability insertVulnerabilityAliases and insertSelfAlias batch queries -- each of which did a hash-lookup subquery against the vuln table -- with two single bulk INSERT statements that use unnest() + JOIN to link all vulnerabilities to their aliases and self-references in one pass. The flattened (hash_kind, hash, alias_space, alias_name) arrays accumulated during the vuln iteration are comparable in size to the arrays already built by the insertAliases pre-pass, so memory usage does not grow significantly relative to what was already held. For VEX with a 2-year lookback (~1.1M vulns), this reduces the alias-linking phase from timing out at 30 minutes to ~43 seconds. Signed-off-by: crozzy <joseph.crosland@gmail.com> Change-Id: Icc408d5593c3eca5832ca32a72fe65f86a6a6964
This fixes a bug where `insertAliases` consumes the single-pass `vulnIter` (backed by `jsonblob.RecordIter`) before the main vulnerability insertion loop runs, resulting in zero vuln rows being inserted. The fix removes the separate `insertAliases` pre-pass and instead collects alias namespaces and aliases during the main `vulnIter` loop, then bulk-inserts them via a separate connection (outside the transaction) after the loop -- preserving the deadlock-avoidance property. Also adds a test using a `sync.Once`-guarded single-pass iterator that reproduces the bug. Signed-off-by: Hank Donnay <hdonnay@redhat.com> Change-Id: I764435cfde1f62b7492dc056824e8b606a6a6964
428280d to
40ee906
Compare
This fixes a transaction conflict where concurrent updaters could attempt to insert the same alias namespaces and cause the entire update to abort.