aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-09-19 17:10:37 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2012-09-19 17:10:37 -0400
commit96cc18eef6489cccefe351baa193f32f12018551 (patch)
tree2ac3b309d143d178d1034f8b59c2a86cfe2a04d0 /doc/src
parentf1f722daccd4789522d7b16211089af6d92eecf0 (diff)
downloadpostgresql-96cc18eef6489cccefe351baa193f32f12018551.tar.gz
postgresql-96cc18eef6489cccefe351baa193f32f12018551.zip
Put back AcceptInvalidationMessages calls in heap_openrv(_extended).
These calls were removed in commit 4240e429d0c2d889d0cda23c618f94e12c13ade7 as part of a general refactoring and improvement of DDL locking. However, there's a problem not solved by the rewrite, which is that GRANT/REVOKE update pg_class.relacl without taking any particular lock on the target table as such. If another backend fails to do AcceptInvalidationMessages, it won't notice a recently-committed change in ACLs. Bug #7557 from Piotr Czachur demonstrates that there's at least one code path in 9.2.0 in which a command fails to do any AcceptInvalidationMessages calls at all, if the current transaction already holds all the locks it will need. Since we're hard up against the release deadline for 9.2.1, fix this by putting back the AcceptInvalidationMessages calls in heap_openrv and heap_openrv_extended, thereby restoring the historical behavior in this area. We ought to look for a more elegant and perhaps more bulletproof solution, but there's no time for that right now.
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions