Re: 24.1.5.1. Multixacts And Wraparound
On Fri, Jun 18, 2021 at 08:51:00AM +0200, Laurenz Albe wrote: > On Thu, 2021-06-17 at 18:31 +, PG Doc comments form wrote: > > In section "24.1.5.1. Multixacts And Wraparound" of > > https://www.postgresql.org/docs/current/routine-vacuuming.html we find the > > following sentence towards the end of the section: > > > > "...If the amount of used member storage space exceeds the amount 50% of the > > addressable storage space." > > > > I am having trouble parsing "...exceeds the amount 50% of the > > addressable..." part. > > > > It seems like the sentence is trying to say "...space exceeds 50% of the > > addressable storage space" or maybe even "...space exceeds the amount of the > > addressable storage space". Which is which? > > +1 > > I think that the second "the amount" in the sentence should be removed. I think it is worse than that. Here is the full paragraph: As a safety device, an aggressive vacuum scan will occur for any table whose multixact-age is greater than . Aggressive vacuum scans will also occur progressively for all tables, starting with those that have the oldest multixact-age, if the amount of used member storage space exceeds the amount 50% of the addressable storage space. Both of these kinds of aggressive scans will occur even if autovacuum is nominally disabled. What does "the amount of used member storage space exceeds 50% of the addressable storage space" mean? -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
Re: Misleading sentence about default privileges
On Thu, Jun 17, 2021 at 09:07:11AM +, PG Doc comments form wrote: > > You can change default privileges only for objects that will be created by > yourself or by roles that you are a member of. > > Yet, altering the default privileges `for role`'s that I am a member of > (i.e. `target_role` in docs), does not affect privileges granted on objects > created by other members of said role. > > Seeing as separating Users (roles with log-in privilege) from Roles > (containing concrete grants, unable to log in) seems a common, and > recommendable pattern, I believe the statement is quite misleading. > > For an example of expected behaviour, see this Stack Overflow question: > https://stackoverflow.com/questions/56237907/why-doesnt-alter-default-privileges-work-as-expected > > The only scenario I can think of where the statement makes sense seems quite > foreign to me: > Scenario: I, say `role_a`, have log-in, and am also a member of another > Role, say `role_b`, which also has login. Only objects created directly by > `role_b` (i.e. not any of its members) are affected. > > I suggest adding something like the following to the documentation: > > " Note that only object created directly by _*target_role*_ , i.e. not any > of its members, will have privileges granted. " I researched this. What it is saying is that you can modify the defaults for your own role, or roles you are a member of. The defaults are applied based on the active role at the time you create an object. Here is an example run as the postgres user: CREATE ROLE demo NOLOGIN; --> ALTER DEFAULT PRIVILEGES FOR ROLE demo GRANT SELECT ON TABLES TO PUBLIC; CREATE TABLE test1 (x INTEGER); --> SET ROLE demo; CREATE TABLE test2 (x INTEGER); \dp test1 Access privileges Schema | Name | Type | Access privileges | Column privileges | Policies +---+---+---+---+-- public | test1 | table | | | \dp test2 Access privileges Schema | Name | Type | Access privileges | Column privileges | Policies +---+---+---+---+-- public | test2 | table | =r/demo +| | --> | | | demo=arwdDxt/demo | | I am trying to think of wording that would make this documentation section clearer, but I can't think of anything. Maybe the entire concept of "active role at time of object creation" needs to be explained more, since there is a lot of focus on owner without the idea that this is really the active role. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
RE: doc: Document how to run regression tests with custom server settings
Hi I was doing regression testing according to the PG-doc at [1]. The modification at 854434c5 seems not correct, could you please take a check at it? >make check PGOPTIONS="-c log_checkpoints=on -c work_mem=50MB" The above command reported an error like this: failed: FATAL: parameter "log_checkpoints" cannot be changed now IMHO, as a sighup GUC, log_checkpoints can't be set in PGOPTIONS, is that correct? >make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf" pg_regress: could not open "test_postgresql.conf" to read extra config: No such file or directory I fixed above problem using command like this: make check EXTRA_REGRESS_OPTS="--temp-config=$(pwd)/test_postgresql.conf" Maybe we can change doc description to tell user he/she should specify the location of " test_postgresql.conf", thoughts? [1] https://www.postgresql.org/docs/devel/regress-run.html Regards, Tang
