commit 2d7ed309ec4e656ce9d6f21f03ea158278f2526d
Author: Jay Pipes <email address hidden>
Date: Thu Aug 16 14:56:47 2018 -0400
placement: use single-shot INSERT/DELETE agg
When replacing a provider's set of aggregate associations, we were
issuing a call to:
DELETE resource_provider_aggregates WHERE resource_provider_id = $rp
and then a single call to:
INSERT INTO resource_provider_aggregates
SELECT $rp, aggs.id
FROM provider_aggregates AS aggs
WHERE aggs.uuid IN ($agg_uuids)
This patch changes the _set_aggregates() function in a few ways.
First, we grab the aggregate's internal ID value when creating new
aggregate records (or grabbing a provider's existing aggregate
associations). This eliminates the need for any join to
provider_aggregates in an INSERT/DELETE statement.
Second, instead of a multi-row INSERT .. SELECT statement, we do
single-shot INSERT ... VALUES statements, one for each added aggregate.
Third, we no longer DELETE all aggregate associations for the provider
in question. Instead, we issue single-shot DELETE statements for only
the aggregates that are being disassociated.
Finally, I've added a number of log debug statements so that we can have
a little more information if this particular patch does not fix the
deadlock issue described in the associated bug.
Reviewed: https:/ /review. openstack. org/592654 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=2d7ed309ec4 e656ce9d6f21f03 ea158278f2526d
Committed: https:/
Submitter: Zuul
Branch: master
commit 2d7ed309ec4e656 ce9d6f21f03ea15 8278f2526d
Author: Jay Pipes <email address hidden>
Date: Thu Aug 16 14:56:47 2018 -0400
placement: use single-shot INSERT/DELETE agg
When replacing a provider's set of aggregate associations, we were
issuing a call to:
DELETE resource_ provider_ aggregates WHERE resource_ provider_ id = $rp
and then a single call to:
INSERT INTO resource_ provider_ aggregates
SELECT $rp, aggs.id
FROM provider_aggregates AS aggs
WHERE aggs.uuid IN ($agg_uuids)
This patch changes the _set_aggregates() function in a few ways. aggregates in an INSERT/DELETE statement.
First, we grab the aggregate's internal ID value when creating new
aggregate records (or grabbing a provider's existing aggregate
associations). This eliminates the need for any join to
provider_
Second, instead of a multi-row INSERT .. SELECT statement, we do
single-shot INSERT ... VALUES statements, one for each added aggregate.
Third, we no longer DELETE all aggregate associations for the provider
in question. Instead, we issue single-shot DELETE statements for only
the aggregates that are being disassociated.
Finally, I've added a number of log debug statements so that we can have
a little more information if this particular patch does not fix the
deadlock issue described in the associated bug.
Change-Id: I87e765305017ea e1424005f7d6f41 9f42a2f8370
Closes-bug: #1786703