sql-runner icon indicating copy to clipboard operation
sql-runner copied to clipboard

sql-runner fails on IF EXISTS statements

Open gabrielcrowdtilt opened this issue 8 years ago • 19 comments

For example, web-incremental step 00-preparation: https://github.com/snowplow/snowplow/blob/master/5-data-modeling/sql-runner/redshift/sql/web-incremental/00-preparation/00-preparation.sql#L25

Gives this output

2015/10/07 04:12:30 EXECUTING 00-preparation (in step 00-preparation @ snowplow): /opt/snowplow/sql_runner/analytics/sql/web-incremental/00-preparation/00-preparation.sql
2015/10/07 04:12:30 FAILURE: 00-preparation (step 00-preparation @ target snowplow), ERROR: ERROR #3F000 schema "snplw_temp" does not exist: 
2015/10/07 04:12:30 
TARGET INITIALIZATION FAILURES:
QUERY FAILURES:
* Query 00-preparation /opt/snowplow/sql_runner/analytics/sql/web-incremental/00-preparation/00-preparation.sql (in step 00-preparation @ target snowplow), ERROR:
  - ERROR #3F000 schema "snplw_temp" does not exist: 

Can sql-runner be made to handle this edge case. It would also allow one to create playbooks for all initial schema and table setup.

gabrielcrowdtilt avatar Oct 07 '15 04:10 gabrielcrowdtilt

/cc @bogaert

alexanderdean avatar Oct 07 '15 08:10 alexanderdean

Using psql:

db00002=# drop schema if exists foobar cascade;
INFO:  Schema "foobar" does not exist and will be skipped
DROP SCHEMA

It has to be a bug in the underlying Golang Postgres driver. We could try to upgrade to v3 of that driver and see if the problem goes away; if not then I think we have to raise a bug with the driver maintainers.

alexanderdean avatar Oct 07 '15 08:10 alexanderdean

Hey @alexanderdean not sure where to go with this ticket as we have this command in our integration-test with no issues.

https://github.com/snowplow/sql-runner/blob/master/integration-tests/postgres-sql/good/1.sql#L3

jbeemster avatar Nov 12 '15 16:11 jbeemster

I have seen this issue when running Snowplow playbooks - this may be a Postgres vs Redshift issue?

alexanderdean avatar Nov 12 '15 16:11 alexanderdean

Quite possible! I will try running this against a Redshift target to re-create.

jbeemster avatar Nov 12 '15 16:11 jbeemster

Thanks Josh!

alexanderdean avatar Nov 12 '15 16:11 alexanderdean

This fails against a Redshift Target with v2 and v3.

jbeemster avatar Nov 12 '15 16:11 jbeemster

Further on this it is not just the DROP SCHEMA IF EXISTS command but also just a CREATE SCHEMA command. Seems to have issues working with schemas in general.

jbeemster avatar Nov 12 '15 17:11 jbeemster

Can you reproduce with psql, or is this only a SQL Runner issue?

alexanderdean avatar Nov 12 '15 17:11 alexanderdean

Can confirm that this is only an issue with SQL Runner, running the same playbook from CLI using psql works exactly as it should. Should we raise an issue with them about this?

jbeemster avatar Nov 12 '15 18:11 jbeemster

That's super weird. It must be a bug in the Golang PG v2 driver. Can we try upgrading to the v3, see if the problem goes away?

alexanderdean avatar Nov 12 '15 18:11 alexanderdean

Did that already sadly.

jbeemster avatar Nov 12 '15 18:11 jbeemster

Let's create a separate ticket to upgrade to v3 of the PG driver in this release anyway...

alexanderdean avatar Nov 12 '15 18:11 alexanderdean

SQL Runner fails when running both of the following commands:

DROP SCHEMA IF EXISTS any_schema_here CASCADE;

-- OR

CREATE SCHEMA any_schema_here;

I tried running both of these lines against a fresh Redshift cluster and they both failed with the: ERROR #3F000 schema "any_schema_here" does not exist:

From psql to the same cluster everything runs as expected.

jbeemster avatar Nov 12 '15 18:11 jbeemster

We also faced the same issue here, but IIRC doing the schema manipulation queries as the only query in a separate step worked, at least on Redshift, but I might be misremembering.

andrioni avatar Nov 12 '15 19:11 andrioni

I've just run into this bug too on 0.4.0.

  • ERROR #3F000 schema "staging" does not exist.

When running DROP SCHEMA IF EXISTS followed by CREATE SCHEMA then commands which depend on the schema.

I can confirm that moving the schema DROP/CREATE into its own step is an effective workaround.

The scripts work ok when run through Navicat, so it's a sql-runner specific thing.

iaingray avatar Jan 07 '16 19:01 iaingray

In case anybody keeps hitting this problem like happend with us: the only way that seemed to solve this was to move

CREATE SCHEMA IF NOT EXISTS snplw_temp;

from the top of 00-preparation to the end of 08-track-queries.

esquire900 avatar Aug 07 '16 09:08 esquire900

Thanks for sharing Simon!

alexanderdean avatar Aug 07 '16 10:08 alexanderdean

Pushing back

alexanderdean avatar Jun 03 '18 15:06 alexanderdean