Open jasonmp85 opened 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.
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.
Not entirely sure whether this is a feature request or a bug report, but various emails have been hitting my inbox of users either:
pg_shard
inshared_preload_libraries
but forgetting to callCREATE EXTENSION
CREATE EXTENSION
but forgetting to everLOAD
pg_shard
(using the above config variable or otherwise)These causes produce a variety of symptoms, but common ones are:
pg_shard
's hooks have not been loaded (caused by lack ofLOAD
)schema "pgs_distribution_metadata" does not exist
(caused by lack ofCREATE
)This is biting enough people that some runtime guidance could help out a lot.