This section summarizes common problems and potential solutions you might
sgr with debug logging
For any issues, running
--verbosity DEBUG will print out extra
debug information and full error tracebacks which can help you understand what's
$ sgr --verbosity DEBUG commit demo/dataset
Inspect engine logs
If you're running the engine through the
sgr engine wrapper, you can inspect
its logs by running:
$ sgr engine log
In other cases, you can inspect the logs of the container that's running the engine directly from Docker:
$ docker logs splitgraph_engine_default # or other container name
Layered querying and Splitfile execution takes too long or gets stuck running SQL
It's possible that the engine is downloading objects needed to satisfy the query in the background, which currently doesn't output the progress. Alternatively, the engine might be having some other connection issues.
To check that, inspect the engine logs
sgr engine log).
Type "geometry" does not exist
This happens if you're trying to download a PostGIS-enabled data image with an engine that doesn't support it. To fix this, upgrade your engine to use PostGIS:
$ sgr engine upgrade --image splitgraph/engine:stable-postgis $ sgr sql "CREATE EXTENSION IF NOT EXISTS postgis"
Then, re-clone the repository.
If there are any consistency issues (e.g. with objects still missing), you can delete the offending repository, clean up loose objects and download it again:
$ sgr rm broken/repository $ sgr cleanup $ sgr clone broken/repository
sgr Engine data/metadata is taking up too much space
Check the space that's used by the engine's data (actual Splitgraph object
files) and metadata (PostgreSQL table data) by running
docker system df -v.
You can also run
sgr status to list
current repositories and space that they take up.
To free up some space, you can:
- Uncheckout (
sgr checkout -u) some repositories: data stored in PostgreSQL tables takes up more space than when stored as Splitgraph objects.
- Delete (
sgr rm) unneeded repositories or images.
- Clean up (
sgr cleanup) Splitgraph objects that are not linked to any images on your engine.
- Vacuum the
PostgreSQL instance backing the engine:
sgr sql --no-transaction "VACUUM FULL". This will delete dead tuples from tables that were checked out and then deleted.
Objects that were downloaded from a different engine or Splitgraph are
considered to be cached locally and can be evicted to save space. The default
cache size is 10GB and can be changed by changing the
configuration flag (in MB). Eviction gets run when objects are downloaded but
you can force it by running:
$ sgr eval "object_manager.run_eviction(, required_space=\\ max(object_manager.get_cache_occupancy() - object_manager.cache_size, 0))"
Waiting for connection...
sgr by default attempts to connect to the engine (and the registry) multiple
times to work around transient network issues or wait for engine to start up.
--verbosity DEBUG to pinpoint what's causing a
connection failure. Common issues are:
- Engine isn't started: check with
sgr engine status, then start it if needed with Docker or with
sgr engine start.
- Wrong username/password or connection parameters: check them in your
You can also check the full configuration parameters currently in use by running
Password input is echoed and not accepted, other output issues
If you're running
sgr in a MINGW terminal (for example, Git Bash), you have to
prefix its invocations with
to avoid output errors and make sure password inputs work properly.
The simplest way to do this is by adding
alias sgr='winpty -Xallow-non-tty sgr' to your
-Xallow-non-tty flag avoids the issue where
winpty fails when piping
data (e.g. Splitfiles) directly to
sgr but only works on
winpty above 0.4.0
--version). For older versions of
winpty, you'll have to run
sgr without it when piping input to it.
Error: input is not a TTY
This can happen if you're on Windows and are trying to pipe input to
that's run through
winpty. To solve this, invoke
winpty or run
Windows/OSX Docker issues
Windows and OSX run Docker in a virtual machine which can cause various issues
Check your Docker daemon is running:
$ docker info $ docker run hello-world
Make sure the Docker VM is started and environment is configured:
$ docker-machine start $ docker-machine env $ eval $(docker-machine env)
Sometimes the IP address of the Docker VM can change, also changing the IP
address of the
sgr engine. To fix that, check the IP of the Docker VM:
$ docker-machine ip
Then, make sure the IP address of the engine is the same (check