New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create_distributed_table gives misleading error when called as non-table-owner #2094

Closed
marcocitus opened this Issue Apr 11, 2018 · 2 comments

Comments

Projects
None yet
4 participants
@marcocitus
Member

marcocitus commented Apr 11, 2018

When a table that contains data is distributed, create_distributed_table may give an error such as:

cannot establish a new connection for placement 374, since DDL has been executed on a connection that is in use

What happens is that Citus connects as the table owner to create the shards (the "DDL") to make sure the shard has the same owner, but then Citus tries to copy data into the shards as the current user, which would require a new connection, but that new connection would not be able to see the new table yet.

We could require that create_distributed_table is always called by the table owner, but that might break some existing workflows. We could only require it when the table contains data, such that we just change the error message into something more meaningful.

@mkurz

This comment has been minimized.

mkurz commented Apr 24, 2018

I just ran into a similar problem: We created a Postgres user (lets call it foouser) which is the owner of all tables, then we ran select create_distributed_table(...) as postgres user which was successfull, however on the workers now all tables were owned by postgres instead foouser (which we created by hand before on all workers). It would be nice if you at least display a warning when create_distributed_table is not called by the table owner.

@kaikuchn

This comment has been minimized.

kaikuchn commented Jul 9, 2018

We could only require it when the table contains data, such that we just change the error message into something more meaningful.

Sounds reasonable to me. I encountered this issue today and a better error message would've been nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment