rjuju / pg_validate_extupgrade Goto Github PK

Hi Julien!

Extension upgrade can contain columns addition to some tables. Those new columns obviously will be the last table attributes. But in the initial extension creation script of a new version they can appear in the middle of the table definition. Usually this improves readability.
In such cases table structures are considered different by pg_validate_extupgrade. From the database point of view such tables are different, but from relational theory point of view they are the same...

What do you think about sorting table attributes by name before comparison?
Of course we could bump into some SELECT * expressions used in an extension (however my opinion is that extension developers shouldn't do that).
Maybe comparison behavior could be configurable...

Best regards, Andrei

Hello, Julien!

This tool looks very useful for me, thank you!
I was unable to run it without specifying the host. It hangs trying to connect on '27.0.0.1'. It seems like a typo in src/lib.rs:56

I'm using this tool to validate my extension zachasme/h3-pg, and it is much better than old my scripts for comparing upgrades and installs. The output is extremely helpful!

I've been trying to debug a specific problem, and I can't quite figure out if it is an issue with pg_validate_extupgrade or my extension:

I have a branch where I've renamed some operator classes and families such that they share the same name, similar to jsonb_ops which has the same name across btree, hash and gin for example. See the change here: https://github.com/zachasme/h3-pg/pull/98/files

When I validate the upgrade locally I get the error:

- mismatch found for Extension h3:
  - in opfamilies:
    installed and upgraded both have 2 OpFamily but some mismatch in them:
      - mismatch found for OpFamily public.h3index_ops:
        - in opfmethod:
          - btree
          + hash

The test passes in CI, however. I suspect it might depend on the order in which the opfmethods are returned.

I have attempted to dig through the codebase and create a failing test, but I can't quite figure out how.

Can you shed some light on this?

Hi, Julien!

I'm trying pg_validate_extupgrade on PG13:

postgres=# select version();
                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 13.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
(1 row)

And it fails with an error on pg_get_statisticsobjdef_columns function:

Connected, server version 130002
thread 'main' panicked at 'Could net get pg_statistic_ext rows: Error { kind: Db, cause: Some(DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E42883), message: "function pg_get_statisticsobjdef_columns(oid) does not exist", detail: None, hint: Some("No function matches the given name and argument types. You might need to add explicit type casts."), position: Some(Original(92)), where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: Some("parse_func.c"), line: Some(627), routine: Some("ParseFuncOrColumn") }) }', src/extension/pg_statistic_ext.rs:44:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Am I doing something wrong?

Hi, Julien!

It seems, last commit in a master branch 6b84639 is broken something.. In my case building fails with a bunch of errors starting with

error[E0583]: file not found for module `guc`
  --> src/lib.rs:26:1
   |
26 | mod guc;
   | ^^^^^^^^
   |
   = help: to create the module `guc`, create file "src/guc.rs"

Best regards, Andrei

Hello, Julien!

I have an idea of a feature for pg_validate_extupgrade.
Contents of some tables in my extension is used to store version-dependent queries. DML on those tables is a part of upgrade script. I think there is a couple of cases, when contents of some extension tables will be version-dependent.
It wold be nice to specify names of such tables to pg_validate_extupgrade for content checking. I think, table contents might be the same with except of column order.