-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for Error: could not execute revoke query: pq: tuple concurrently updated
#352
base: main
Are you sure you want to change the base?
Conversation
I'm working on adding test coverage for this issue / fix. The goal is to run the terraform code in |
Go bumped from 1.20 to 1.12.1 in commit 26d632a
Tests are failing because
and because When developing locally, I build the provider and copy it to the correct location locally on disk, before running |
* Using terratest just wasn't working out - it isn't designed for testing a provider * github.com/hashicorp/terraform-plugin-sdk/v2/helper/resource looks like the right option but I don't have the time to learn it right now.
@cyrilgdn Could you review this please? |
I've made a beta release targeting this branch, and in my case, the |
Hi @kylejohnson, thanks for looking at this issue. I'm testing out the beta and am now getting this error: This error happens on both postgresql_grant and postgresql_default_privileges |
Could you provide an example of code that recreates your error? |
It's somewhat difficult to recreate since it's timing dependent, but something like this should do it. resource "postgresql_grant" "grant" { resource "postgresql_default_privileges" "tables" { I suspect that the deadlock occurs between the default privileges and the grants since they both apply a ton of table grants I ended up setting max concurrency back to 1 and this issue went away again. |
I have tested 1.21.1-beta.1 and concurrency issues are not fixed. The fix provided by giner works. This one not. When terraform is refreshing state, it continuously slows down until gets stuck. Never completes. May be good to understand would be, that I use provider inside a terraform module I built for quite standard function access. Then every single function, has own terraform file, which uses module, to create standard function user and access for it. Even if you run terraform with concurrency 1, and setup database connection limit to 1, still it creates like 20 processes, each for single function, and tries to refresh state for 20 modules. Please make that giner commit into code, as it looks it works perfectly (build and tested it locally). |
schema := d.Get("schema").(string) | ||
if err := pgLockSchema(txn, schema); err != nil { | ||
return err | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do it next to where we call pgLockRole
(e.g. around line 171) ?
And actually as schema
is optional if postgresql_grant
is used at database level, we should put this in the else of if objectType == "database" {
line 176
if objectType == "database" {
if err := pgLockDatabase(txn, database); err != nil {
return err
}
} else {
// Obtain a lock to avoid `Error: could not execute revoke query: pq: tuple concurrently updated`
schema := d.Get("schema").(string)
if err := pgLockSchema(txn, schema); err != nil {
return err
}
}
@kylejohnson do you have any time to address @cyrilgdn's feedback? The changes you've made here would be helpful for me as we are running into the same issue on #178. This is error is quite inconvenient for me as we need to re-run terraform multiple times so I'd be happy to take a stab at addressing the feedback if needed. |
f2c2e47
to
dea1401
Compare
This should be a fix for #178.
From what I can tell, the locks created in
pgLockRole
andpgLockDatabase
were not sufficient to cover cases when we're messing with a schema, such asREVOKE ALL PRIVILEGES ON SCHEMA %s FROM %s
.I created an example in
examples/issues/178
in which I was able to reproduce the error in nearly 50% ofterraform apply
orterraform destroy
operations. With this change, the error hasn't been reproduced in over 30 such operations.