Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

syntheticprivilegecache: scan all privileges at startup #93557

Merged
merged 2 commits into from
Dec 14, 2022
Merged

syntheticprivilegecache: scan all privileges at startup #93557

merged 2 commits into from
Dec 14, 2022

Commits on Dec 14, 2022

  1. syntheticprivilegecache: move caching logic out of sql 

    This is a pure refactor to move the logic for caching synthetic privileges
from the sql package. This will make it easier to add features later.
Epic: none

Release note: None
    @ajwerner
    ajwerner committed Dec 14, 2022
    Configuration menu
    Copy the full SHA
    13c07ce View commit details
    Browse the repository at this point in the history

  2. syntheticprivilegecache: scan all privileges at startup 

    Fixes cockroachdb#93182

This commit attempts to alleviate the pain caused by synthetic virtual table
privileges introduced in 22.2. We need to fetch privileges for virtual tables
to determine whether the user has access. This is done lazily. However, when a
user attempts to read a virtual table like pg_class or run SHOW TABLES it will
force the privileges to be determined for each virtual table (of which there
are 290 at the time of writing). This sequential process can be somewhat slow
in a single region cluster and will be very slow in an MR cluster.

This patch attempts to somewhat alleviate this pain by scanning the table
eagerly during server startup.

Release note (performance improvement): In 22.2 we introduced privileges on
virtual tables (system catalogs like pg_catalog, information_schema, and
crdb_internal). A problem with this new feature is that we now must fetch those
privileges into a cache before we can use those tables or determine their
visibility in other system catalogs. This process used to occur on-demand, when
the privilege was needed. Now we'll fetch these privileges eagerly during
startup to mitigate the latency when accessing pg_catalog right after the
server boots up.
    @ajwerner
    ajwerner committed Dec 14, 2022
    Configuration menu
    Copy the full SHA
    268d0f4 View commit details
    Browse the repository at this point in the history