Mistake in documentation for CREATE STATISTICS
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/sql-createstatistics.html Description: The example on https://www.postgresql.org/docs/11/sql-createstatistics.html seems wrong: instead of "EXPLAIN ANALYZE SELECT ..." it should say "EXPLAIN SELECT ...". If changed that way, the query optimizer estimates the number of rows at 1 and then 100 after statistics are created which is indeed how many the query returns. In the current wording, with ANALYZE, the query optimizer estimates the number of rows at 100 for both the first and second select. Tested on PostgreSQL 11.
ATTACH/DETACH partitions and locking
Hello, According to patch[1] and after playing with v12 beta1 I think that this item can be dropped from "5.11.3. Implementation Using Inheritance" section of v12 docs: "Some operations require a stronger lock when using declarative partitioning than when using table inheritance. For example, adding or removing a partition to or from a partitioned table requires taking an ACCESS EXCLUSIVE lock on the parent table, whereas a SHARE UPDATE EXCLUSIVE lock is enough in the case of regular inheritance." Small patch attached. [1] ATTACH/DETACH PARTITION CONCURRENTLY https://www.postgresql.org/message-id/flat/CAKJS1f9QjUwQrio20Pi=ychmnouf4z3sfn8sqxaacwreg6k...@mail.gmail.com -- - Pavel Luzanov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index ed2d9c60d5..f9feec3125 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -4057,17 +4057,6 @@ ALTER INDEX measurement_city_id_logdate_key might be poor.) - - - -Some operations require a stronger lock when using declarative -partitioning than when using table inheritance. For example, adding -or removing a partition to or from a partitioned table requires taking -an ACCESS EXCLUSIVE lock on the parent table, -whereas a SHARE UPDATE EXCLUSIVE lock is enough -in the case of regular inheritance. - -
Re: ATTACH/DETACH partitions and locking
On 2019-Jun-13, Pavel Luzanov wrote: > Hello, > > According to patch[1] and after playing with v12 beta1 I think that this > item can be dropped from "5.11.3. Implementation Using Inheritance" section > of v12 docs: > > "Some operations require a stronger lock when using declarative partitioning > than when using table inheritance. For example, adding or removing a > partition to or from a partitioned table requires taking an ACCESS EXCLUSIVE > lock on the parent table, whereas a SHARE UPDATE EXCLUSIVE lock is enough in > the case of regular inheritance." Hmm ... while you're correct that ALTER TABLE ATTACH PARTITION no longer uses AccessExclusive lock, ALTER TABLE DETACH PARTITION continues to. So we could remove the "adding to" bit of the paragraph, but not remove it completely. https://www.postgresql.org/message-id/CA%2BTgmoY13KQZF-%3DHNTrt9UYWYx3_oYOQpu9ioNT49jGgiDpUEA%40mail.gmail.com -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
More obvious clarification is needed about how RLS interacts with views
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/sql-createpolicy.html Description: It's not clear enough from reading the documentation on RLS security policy that schema designers need to pay special attention to views and their ownership. (Views will bypass RLS security in the common case that they are owned by a super user.) I have seen this misunderstanding lead to unexpected data exposure. This *is* clarified at the very bottom of the Notes section on the `create policy` document, but I believe it justifies having a clear and prominent call out. Thank you!
