From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: bossartn@amazon.com
Cc: andres@anarazel.de
Cc: pgsql-hackers@lists.postgresql.org
Cc: robertmhaas@gmail.com
Cc: schnjere@amazon.com
Cc: pgsql-hackers@postgresql.org
Cc: lalbin@scharp.org
Subject: Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack
Date: Fri, 27 Jul 2018 13:15:42 +0900
Message-ID: <20180727041542.GH1754@paquier.xyz> (raw)
In-Reply-To: <20180727.123702.77822416.horiguchi.kyotaro@lab.ntt.co.jp>
References: <20180726204127.GA1754@paquier.xyz>
<3D4F2733-92AE-4B74-8912-3C611B027721@amazon.com>
<20180727023123.GE1754@paquier.xyz>
<20180727.123702.77822416.horiguchi.kyotaro@lab.ntt.co.jp>
On Fri, Jul 27, 2018 at 12:37:02PM +0900, Kyotaro HORIGUCHI wrote:
> I intended the same as Bossart said. It is not reasonable that
> VACUUM and VACUUM FULL behaves differently on rejection for the
> same reason. The objective of the first (or early) check is
> rejecting (non-superuser's) unprivileged VACUUM FULL. Any
> possible modifications on a syscache tuple before taking a lock
> doesn't seem to harm in the point of view. Anyway the lock
> acquired in expand_vacuum_rel is not held until vacuum_rel.
Thinking about it harder, it is possible to pass down a status pointer
that the callback of RangeVarGetRelidExtended could fill if we pass it
down using the argument list. This would need special handling for the
case where expand_vacuum_rel() is NIL but that would be workable. If
vacuum_check_rel() does not need to work with elevel >= ERROR, then the
set of log messages remains the same.
> Apart from the discussion above, it is uneasy for me that the
> messages seem heavily affected by the callers context.
Sure, the patch for vacuum is still heavily WIP. I am not much happy
about that either.
>> Regarding those patches, I am pretty happy how things turn out for
>> TRUNCATE and REINDEX, way less for VACUUM, so getting 0001 and 0003
>> committed first makes the most sense to me as their logic is rather
>> straight-forward (well way of speaking ;p ).
>
> About 0001, I'm not sure what the "session-level" means but it
> looks fine and works as expected. 0003 looks fine overall.
What I mean here is checking the interactions with other backends,
truncate_check_session is the best name I could come up with.
truncate_check_activity was another. I am not attached to a single
name, if you have an ideaof course please feel free.
> I think I heard that gender-free wording is appreciated but it
> might be only about documentation.
Sure.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../20180727041542.GH1754@paquier.xyz/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, horiguchi.kyotaro@lab.ntt.co.jp, bossartn@amazon.com, andres@anarazel.de, pgsql-hackers@lists.postgresql.org, robertmhaas@gmail.com, schnjere@amazon.com, pgsql-hackers@postgresql.org, lalbin@scharp.org
Subject: Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack
In-Reply-To: <20180727041542.GH1754@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox