Improve behavior of concurrent TRUNCATE

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Improve behavior of concurrent TRUNCATE
Date: 2018-08-06 16:58:16
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi all,

This is a second thread I am spawning for the previous thread "Canceling
authentication due to timeout aka Denial of Service Attack":

And this time the discussion is about TRUNCATE, as the former thread
discussed about a family of failures hence it is harder to catch the
proper attention. The problem is that when we look for the relation OID
of the relation to truncate, we don't use a callback with
RangeVarGetRelidExtended, causing a lock acquire attempt to happen
before checking the privileges on the relation for the user running the

Attached is a patch I have been working on which refactors the code of
TRUNCATE in such a way that we check for privileges before trying to
acquire a lock, without any user-facing impact (I have reworked a couple
of comments compared to the last version). This includes a set of tests
showing the new behavior.

Like cbe24a6, perhaps we would not want to back-patch it? Based on the
past history (and the consensus being reached for the REINDEX case would
be to patch only HEAD), I would be actually incline to not back-patch
this stuff and qualify that as an improvement. That's also less work
for me at commit :)


Attachment Content-Type Size
0001-Refactor-TRUNCATE-execution-to-avoid-too-early-lock-.patch text/x-diff 10.0 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2018-08-06 17:07:49 Re: Standby trying "restore_command" before local WAL
Previous Message Stephen Frost 2018-08-06 16:11:56 Re: Standby trying "restore_command" before local WAL