On 10/3/18, 12:54 AM, "Michael Paquier" <michael@paquier.xyz> wrote:
> - Inheritance trees have the same problem, so it would be nice to
> mention them as well.
Done.
> - One workaround, which we could document (?), would be to list leaves
> of a partition tree individually so as their locks are checked one by
> one.
Done.
> + Specifies that <command>ANALYZE</command> should not wait for any
> + conflicting locks to be released: if a relation cannot be locked
>
> Perhaps it would be more precise to tell when "beginning to work on a
> relation" because the restrictions in row samplings?
Done.
Here is what I have so far for the docs:
Specifies that ANALYZE should not wait for any conflicting
locks to be released before beginning work on a relation: if a
relation cannot be locked immediately without waiting, the
relation is skipped. Note that even with this option, ANALYZE
may still block when opening the relation's indexes or when
acquiring sample rows from leaf partitions, table inheritance
children, and some types of foreign tables. Also, while
ANALYZE ordinarily processes all leaf partitions of specified
partitioned tables, this option will cause ANALYZE to skip all
leaf partitions if there is a conflicting lock on the
partitioned table. Therefore, it is recommended to list each
leaf partition individually in the ANALYZE command when using
the SKIP_LOCKED option.
Specifies that VACUUM should not wait for any conflicting
locks to be released before beginning work on a relation: if a
relation cannot be locked immediately without waiting, the
relation is skipped. Note that even with this option, VACUUM
may still block when opening the relation's indexes. Also,
while VACUUM ordinarily processes all leaf partitions of
specified partitioned tables, this option will cause VACUUM to
skip all leaf partitions if there is a conflicting lock on the
partitioned table. Therefore, it is recommended to list each
leaf partition individually in the VACUUM command when using
the SKIP_LOCKED option.
Nathan
