Improve TRUNCATE by avoiding early lock queue
A caller of TRUNCATE could previously queue for an access exclusive lock
on a relation it may not have permission to truncate, potentially
interfering with users authorized to work on it. This can be very
intrusive depending on the lock attempted to be taken. For example,
pg_authid could be blocked, preventing any authentication attempt to
happen on a PostgreSQL instance.
This commit fixes the case of TRUNCATE so as RangeVarGetRelidExtended is
used with a callback doing the necessary ACL checks at an earlier stage,
avoiding lock queuing issues, so as an immediate failure happens for
unprivileged users instead of waiting on a lock that would not be
taken.
This is rather similar to the type of work done in cbe24a6 for CLUSTER,
and the code of TRUNCATE is this time refactored so as there is no
user-facing changes. As the commit for CLUSTER, no back-patch is done.
Reported-by: Lloyd Albin, Jeremy Schneider
Author: Michael Paquier
Reviewed by: Nathan Bossart, Kyotaro Horiguchi
Discussion: https://postgr.es/m/152512087100.19803.12733865831237526317@wrigleys.postgresql.org
Discussion: https://postgr.es/m/20180806165816.GA19883@paquier.xyz
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/f841ceb26d701e7f5f48190bf7290c400cba30a2
Modified Files
--------------
src/backend/commands/tablecmds.c | 84 ++++++++++++++-----
src/test/isolation/expected/truncate-conflict.out | 99 +++++++++++++++++++++++
src/test/isolation/isolation_schedule | 1 +
src/test/isolation/specs/truncate-conflict.spec | 38 +++++++++
4 files changed, 204 insertions(+), 18 deletions(-)