Horton

Re: PG 12 draft release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Ian Barwick <ian.barwick@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-06-12T21:25:37Z
Lists: 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 →

  1. doc: PG 12 relnotes: update wording on truncate/vacuum item

  2. docs: PG 12 relnotes, update btree items

  3. doc: PG 12 relnotes, list added snowball/FTS languages

  4. doc: PG 12 relnotes, merge new SQL partition function items

  5. docs: PG 12 release notes, support functions

  6. docs: PG 12 relnote adjustments based on feedback from Tom Lane

  7. docs: adjust RECORD PG 12 relnote item

  8. doc: adjust PG 12 relnotes item on float digit adjustment

  9. doc: adjustments for PG 12 release notes

  10. docs: fix duplicate wording in PG 12 release notes

  11. doc: properly attibute PG 12 pgbench release note item

  12. doc: PG 12 release notes: normalize attribution names

  13. Refactor the fsync queue for wider use.

  14. Add "split after new tuple" nbtree optimization.

  15. Add nbtree high key "continuescan" optimization.

  16. Allow amcheck to re-find tuples using new search.

  17. Consider secondary factors during nbtree splits.

  18. Partial implementation of SQL/JSON path language

  19. Allow extensions to generate lossy index conditions.

  20. Make TupleTableSlots extensible, finish split of existing slot type.

  21. Reduce path length for locking leaf B-tree pages during insertion

On Wed, May 22, 2019 at 04:50:14PM +0900, Ian Barwick wrote:
> On 5/22/19 4:26 PM, Michael Paquier wrote:
> > On Wed, May 22, 2019 at 09:19:53AM +0900, Ian Barwick wrote:
> > > the last two items are performance improvements not related to authentication;
> > > presumably the VACUUM item would be better off in the "Utility Commands"
> > > section and the TRUNCATE item in "General Performance"?
> > 
> > I agree with removing them from authentication, but these are not
> > performance-related items.  Instead I think that "Utility commands" is
> > a place where they can live better.
> > 
> > I am wondering if we should insist on the DOS attacks on a server, as
> > non-authorized users are basically able to block any tables, and
> > authorization is only a part of it, one of the worst parts
> > actually...  Anyway, I think that "This prevents unauthorized locking
> > delays." does not provide enough details.  What about reusing the
> > first paragraph of the commits?  Here is an idea:
> > "A caller of TRUNCATE/VACUUM/ANALYZE could previously queue for an
> > access exclusive lock on a relation it may not have permission to
> > truncate/vacuum/analyze, potentially interfering with users authorized
> > to work on it.  This could prevent users from accessing some relations
> > they have access to, in some cases preventing authentication if a
> > critical catalog relation was blocked."
> 
> Ah, if that's the intent behind/use for those changes (I haven't looked at them
> in any detail, was just scanning the release notes) then it certainly needs some
> explanation along those lines.

Since we did not backpatch this fix, I am hesitant to spell out exactly
how to exploit this DOS attack.  Yes, people can read it in the email
archives, and commit messages, but I don't see the value in spelling it
out the release notes too.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +