Detect incomplete installations and provide useful error

[citus-github-bot]

Issue by jasonmp85
Friday Mar 20, 2015 at 20:01 GMT
Originally opened as citusdata/pg_shard#93

---

Not entirely sure whether this is a feature request or a bug report, but various emails have been hitting my inbox of users either:

• Putting pg_shard in shared_preload_libraries but forgetting to call CREATE EXTENSION
• Calling CREATE EXTENSION but forgetting to ever LOAD pg_shard (using the above config variable or otherwise)

These causes produce a variety of symptoms, but common ones are:

• Running a query against a distributed table but actually hitting the local table because pg_shard's hooks have not been loaded (caused by lack of LOAD)
• Calling a utility command and having it fail with the error schema "pgs_distribution_metadata" does not exist (caused by lack of CREATE)

This is biting enough people that some runtime guidance could help out a lot.

[citus-github-bot]

Comment by jasonmp85
Friday Mar 20, 2015 at 20:03 GMT

---

To protect against users accidentally hitting a local table when pg_shard is not loaded, we could add a trigger to those tables (this could be part of master_create_distributed_table's logic) so that any queries involving them fail with a pg_shard related error message explaining that the table is distributed and they must LOAD pg_shard to use it.

[citus-github-bot]

Comment by jasonmp85
Friday Mar 20, 2015 at 20:07 GMT

---

As for forgetting CREATE, this is a little tougher. One of us recently hit it while trying to run cstore_fdw's regression tests when pg_shard was also loaded. The COPY commands the tests were calling triggered pg_shard's logic. On one hand, we want the user to know about the misconfiguration, but on the other hand, putting anything in the output would break other test suites.

I'm thinking we send something only to the server log (possible?) to have a record that pg_shard is misconfigured, but otherwise just make the hook act as a no-op if the CREATE EXTENSION command hasn't yet been run. After all, this is probably a more rare case, since users must run CREATE EXTENSION to get access to the functions for distributing tables.

[ozgune]

@jasonmp85 and @onderkalaci, do we have learnings here that could apply to the Citus extension experience? I'm adding @samay-sharma and @lithp to this issue since they are working on our tutorials and documentation.

[onderkalaci]

Currently CitusDB errors out when a user issues CREATE EXTENSION citusdb; if citusdb is not in shared_preload_libraries.

The other problem, (i.e., when citusdb is added to shared_preload_libraries but not created), does not apply to citusdb. We had a similar issue, but, this PR fixed it. Basically, testing this easy. Add citusdb to shared_preload_libraries and run postgres' installcheck regression tests. (I personally do this with and without CREATE EXTENSION citusdb is issued before sending any change to PR.)

So, I think we can close this issue. What do you think @jasonmp85 ?

[byucesoy]

I did some tests;

• Run" CREATE EXTENSION ..." without adding citus to shared libraries first.
  PostgreSQL gave error message:

ERROR: Citus can only be loaded via shared_preload_libraries
HINT: Add citus to shared_preload_libraries configuration variable in postgresql.conf in master and workers. Note that citus should be at the beginning of shared_preload_libraries.

• Adding citus to shared libraries but do not create extension, then run PostgreSQL's installcheck;
  All tests passed.
• Adding citus to shared libraries and create extension, then run PostgreSQL's installcheck;
  All tests passed.

What do you guys think? Should we close the issue?

[byucesoy]

@jasonmp85

Since you mentioned, I also run regression tests of cstore_fdw with and without creating citus extension. Both configurations passed the tests.

[onderkalaci]

Yes, I think these tests cover the two cases that the issue is opened for. I think we can close the issue, but let's wait @jasonmp85 if he has any further comments.

[jasonmp85]

I'll close the issue. Sounds like we have mostly solved this.

There's still one edge case: loading the extension, creating the extension, then removing the extension from shared_preload_libraries. This seems like quite the outlier, though, so we can pass on it for now.