pg_upgrade does not upgrade pg_stat_statements properly - Mailing list pgsql-hackers

From Dave Cramer
Subject pg_upgrade does not upgrade pg_stat_statements properly
Date
Msg-id CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com
Whole thread Raw
Responses Re: pg_upgrade does not upgrade pg_stat_statements properly  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
Upgrading from 
10.5 to 13.3 using pg_upgrade -k

The following is the result of an upgrade

select * from pg_extension ;
  oid  |      extname       | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition
-------+--------------------+----------+--------------+----------------+------------+-----------+--------------
 12910 | plpgsql            |       10 |           11 | f              | 1.0        |           |
 16403 | pg_stat_statements |       10 |         2200 | t              | 1.5        |           |
(2 rows)

test=# \df+ pg_stat_statements_reset
                                                                                              List of functions
 Schema |           Name           | Result data type | Argument data types | Type | Volatility | Parallel | Owner | Security |     Access privileges     | Language |       Source code        | Description
--------+--------------------------+------------------+---------------------+------+------------+----------+-------+----------+---------------------------+----------+--------------------------+-------------
 public | pg_stat_statements_reset | void             |                     | func | volatile   | safe     | davec | invoker  | davec=X/davec            +| c        | pg_stat_statements_reset |
        |                          |                  |                     |      |            |          |       |          | pg_read_all_stats=X/davec |          |                          |
(1 row)

And this is from creating the extension in a new db on the same instance

foo=# select * from pg_extension ;
  oid  |      extname       | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition
-------+--------------------+----------+--------------+----------------+------------+-----------+--------------
 12910 | plpgsql            |       10 |           11 | f              | 1.0        |           |
 16393 | pg_stat_statements |       10 |         2200 | t              | 1.8        |           |
(2 rows)

foo=# \df+ pg_stat_statements_reset
                                                                                                                    List of functions
 Schema |           Name           | Result data type |                        Argument data types                         | Type | Volatility | Parallel | Owner | Security | Access privileges | Language |         Source code          | Description
--------+--------------------------+------------------+--------------------------------------------------------------------+------+------------+----------+-------+----------+-------------------+----------+------------------------------+-------------
 public | pg_stat_statements_reset | void             | userid oid DEFAULT 0, dbid oid DEFAULT 0, queryid bigint DEFAULT 0 | func | volatile   | safe     | davec | invoker  | davec=X/davec     | c        | pg_stat_statements_reset_1_7 |
(1 row)

Notice the upgraded version is 1.5 and the new version is 1.8

I would think somewhere in the upgrade of the schema there should have been a create extension pg_stat_statements ?

Dave
Dave Cramer

pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: Re: row filtering for logical replication
Next
From: Zhihong Yu
Date:
Subject: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers