Re: Statistics Import and Export

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, alvherre(at)alvh(dot)no-ip(dot)org
Subject: Re: Statistics Import and Export
Date: 2024-09-08 02:02:00
Message-ID: CACJufxGmdV-9c7M_fs-2mGBMj1XiVqdOkW0NvibmpBJqedo1uQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 6, 2024 at 1:34 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>>
>>
>> this part elevel should always be ERROR?
>> if so, we can just
>
>
> I'm personally dis-inclined to error on any of these things, so I'll be leaving it as is. I suspect that the proper balance lies between all-ERROR and all-WARNING, but time will tell which.
>
somehow, i get it now.

>>
>> relation_statistics_update and other functions
>> may need to check relkind?
>> since relpages, reltuples, relallvisible not meaning to all of relkind?
>
>
> I'm not able to understand either of your questions, can you elaborate on them?
>

Please check my attached changes.
also see the attached cf-bot commit message.

1. make sure these three functions: 'pg_set_relation_stats',
'pg_restore_relation_stats','pg_clear_relation_stats' proisstrict to true.
because in
pg_class catalog, these three attributes (relpages, reltuples, relallvisible) is
marked as not null. updating it to null will violate these constraints.
tom also mention this at [

2.refactor relation_statistics_update. first sanity check first argument
("relation").
not all kinds of relation can pass on
relation_statistics_update, for example view. so do the sanity check.
also do sanity check for the remaining 3 arguments.
if not ok, ereport(elevel...), return false immediately.

3.add some tests for partitioned table, view, and materialized view.

4. minor sanity check output of "attnum = get_attnum(reloid,
NameStr(*attname));"

5.
create table t(a int, b int);
alter table t drop column b;
SELECT pg_catalog.pg_set_attribute_stats(
relation => 't'::regclass,
attname => 'b'::name,
inherited => false::boolean,
null_frac => 0.1::real,
avg_width => 2::integer,
n_distinct => 0.3::real);

ERROR: attribute 0 of relation with OID 34316 does not exist
The error message is not good, i think.
Also, in this case, I think we may need soft errors.
instead of returning ERROR, make it return FALSE would be more ok.

6. there are no "inherited => true::boolean,"
tests for pg_set_attribute_stats.
aslo there are no partitioned table related tests on stats_import.sql.
I think we should add some.

7. the doc output, functions-admin.html, there are 4 same warnings.
Maybe one is enough?

8. lock_check_privileges function issue.
------------------------------------------------
--asume there is a superuser jian
create role alice NOSUPERUSER LOGIN;
create role bob NOSUPERUSER LOGIN;
create role carol NOSUPERUSER LOGIN;
alter database test owner to alice
GRANT CONNECT, CREATE on database test to bob;
\c test bob
create schema one;
create table one.t(a int);
create table one.t1(a int);
set session AUTHORIZATION; --switch to superuser.
alter table one.t1 owner to carol;
\c test alice
--now current database owner alice cannot do ANYTHING WITH table one.t1,
like ANALYZE, SELECT, INSERT, MAINTAIN etc.

so i think your relation_statistics_update->lock_check_privileges part is wrong?
also the doc:
"The caller must have the MAINTAIN privilege on the table or be the
owner of the database."
should be
"The caller must have the MAINTAIN privilege on the table or be the
owner of the table"
?

Attachment Content-Type Size
v28-0001-minor-refactor-based-on-28j.no-cfbot application/octet-stream 17.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Tom Lane 2024-09-07 23:09:40 Re: [PATCH] Add roman support for to_number function