Re: pgstat: allow a stats kind to use its own dedicated dsa/dshash - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: pgstat: allow a stats kind to use its own dedicated dsa/dshash
Date
Msg-id CAN12+Y+SGAY_x4CgvyM298ZxCURzzcBdDH-8vukuj=0arjmZXQ@mail.gmail.com
Whole thread
In response to Re: pgstat: allow a stats kind to use its own dedicated dsa/dshash  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
> > Done.  v4 is split into two patches.
>
> I have spent some time on that, still in the middle of it, and for now
> I am attaching my edits as of a v5-0003 that can apply on top of your
> set of two patches (re-attached, these are untouched).

Thanks!

v6 brings in your edits. I agree with them. I also made some minor
comment changes.
The other substantial changes are:

v6-0001:

1/

@@ -1062,9 +1178,15 @@ pgstat_drop_entry(PgStat_Kind kind, Oid dboid,
uint64 objid,
                                  bool missing_ok)
 {
        PgStat_HashKey key = {0};
+       dshash_table *hash;
        PgStatShared_HashEntry *shent;
        bool            freed = true;

+       Assert(kind >= PGSTAT_KIND_MIN && kind <= PGSTAT_KIND_MAX);
+       Assert(pgStatLocal.kind_hash[kind] != NULL);
+
+       hash = pgStatLocal.kind_hash[kind];
+

These asserts should be an ERROR instead. pgstat_drop_entry() can be called
before the kind is registered, as is the case in
pgstat_execute_transactional_drops.
For example if a custom stats extension is removed from config. In that case
kind_hash[kind] is NULL, and this would dereference it before
missing_ok is reached.
I changed this to return true when missing_ok is set, and ERROR
otherwise. I could
not find any other paths that need this handling.

Of course, there is also the alternate case where we associate a kind
id with a completely
different kind on startup, and in that case, it's ok to drop the
entries. All WAL/2PC records
store is a kind_id, and I don't think we need anything more complex.

2/

Renamed all_hashes/num_hashes to var_hashes/num_var_hashes.

3/

Removed test_custom_stats_var_is_own_hash(). I agree with you. I was thinking
about this one yesterday, but we have enough safeguards in place.

v6-0002:

4/ The existing TAP test was missing the own_hash column.

--
Sami

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: WAL segment file descriptor leak on read errors can PANIC the server
Next
From: Bharath Rupireddy
Date:
Subject: Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers