You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix#321 replaces postgresql_grant all the time. (#476)
Fixes#321
Fix based on [doctolib's
fork](doctolib@1caee37)
version 1.19.0, with [PR
135](#135),
the postgresql_grant resource gets re-created when there is a change.
Replacing the resource is not a good idea because the "destroy/create"
operations are completely separate. i.e. they are not atomic which means
(given the example in the "Steps to Reproduce" section above) for a
short moment between the 2 operations the public role loses access to
the public schema. If for any reason Terraform fails midway or it gets
interrupted, users will end up not being able to access the objects in
the public schema. This is what happens in the PostgreSQL log:
```
2023-07-11 14:50:05.989 UTC [1673] LOG: statement: BEGIN READ WRITE
2023-07-11 14:50:06.000 UTC [1673] LOG: statement: REVOKE ALL PRIVILEGES ON SCHEMA "public" FROM "public"
2023-07-11 14:50:06.001 UTC [1673] LOG: statement: COMMIT
2023-07-11 14:50:06.033 UTC [1675] LOG: statement: BEGIN READ WRITE
2023-07-11 14:50:06.043 UTC [1675] LOG: statement: REVOKE ALL PRIVILEGES ON SCHEMA "public" FROM "public"
2023-07-11 14:50:06.044 UTC [1675] LOG: statement: GRANT USAGE ON SCHEMA "public" TO "public"
2023-07-11 14:50:06.045 UTC [1675] LOG: statement: COMMIT
```
In our case we're only removing ForceNew from privileges, as this fixes
our use case, but the overall solution allows every schema to be updated
instead of recreated.
Introduced a "getter" in order to fix [PR
135](#135)
original issue that caused the introduction of "ForceNew".
> Originally, the privileges argument did not force recreation of the
resource.
This was a problem because it meant that when changing the privileges in
a grant resource, the update function would be triggered and would
receive only the new configuration. So the revocation would not revoke
the old permissions, but the new one, which is not very useful.
....
I could not find a way to fetch the privilege stored in the state, &
setting the argument to ForceNew solved this problem. So I did that.
Fetching the privilege stored in state is the job of our new getter,
this way we don't have to "ForceNew" everything.
I think we might be able to keep a single "Create" function if we
wanted, checking d.IsResourceNew() to decide if we should use the old
one or new one, but the solution from doctolib seems robust enough.
0 commit comments