citusdata / pg_shard

ATTENTION: pg_shard is superseded by Citus, its more powerful replacement
https://github.com/citusdata/citus
GNU Lesser General Public License v3.0
1.06k stars 63 forks source link

Detect incomplete installations and provide useful error #93

Open jasonmp85 opened 9 years ago

jasonmp85 commented 9 years ago

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

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

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

jasonmp85 commented 9 years ago

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.

jasonmp85 commented 9 years ago

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.