Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

Nathan Bossart <bossartn@amazon.com>

From: "Bossart, Nathan" <bossartn@amazon.com>

To: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>

Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Robert Haas <robertmhaas@gmail.com>, "Schneider, Jeremy" <schnjere@amazon.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, "Albin, Lloyd P" <lalbin@scharp.org>

Date: 2018-07-26T15:40:07Z

Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Improve VACUUM and ANALYZE by avoiding early lock queue
- a556549d7e6d 12.0 landed
Improve TRUNCATE by avoiding early lock queue
- f841ceb26d70 12.0 landed
Restrict access to reindex of shared catalogs for non-privileged users
- 87330e21c327 11.0 landed
- 661dd23950f2 12.0 landed
Improve behavior of concurrent CLUSTER.
- cbe24a6dd8fb 9.2.0 cited

On 7/26/18, 10:07 AM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> The first time we use this callback, the relation won't be locked, so
> isn't it possible that we won't get a valid tuple here?  I did notice
> that callbacks like RangeVarCallbackForRenameRule,
> RangeVarCallbackForPolicy, and RangeVarCallbackForRenameTrigger assume
> that the relation can be concurrently dropped, but
> RangeVarCallbackOwnsRelation does not.  Instead, we assume that the
> syscache search will succeed if the given OID is valid.  Is this a
> bug, or am I missing something?

Please pardon the noise.  I see that we don't accept invalidation
messages until later on in RangeVarGetRelidExtended(), at which point
we'll retry and get InvalidOid for concurrently dropped relations.

Nathan