Murat Tuncer
Murat Tuncer
yes, unfortunately this is a known issue that won't be fixed. It involves a file operation that can not be rolled back.
We have added a different storage mechanism that is pending release under `develop` branch. This should solve the truncate issue you are having. But it is not of release quality...
Some slowdown is expected when you have such low block row count. Reducing block row count causes more disk accesses when writing and reading. Why do you need to change...
we haven't been very active lately. use now postgres internal storage is checked into develop branch. This change enables streaming replication on cstore_fdw tables. There are some pending task to...
hi @rmadiwaledba thanks for the report, I can reproduce it in our end. looks like our copy code does not play nice with serial fields. As you stated, copy works...
yes, it is a bug
Hi @luiscape Thanks for reporting the issue. Yes, this is somewhat related to how cstore_fdw uses memory. Your query seems to open many parallel cstore_fdw sessions for daily rollup tables,...
Hey @luiscape Is there any update on this one ?
Could you check file descriptor limit for your system ? (ulimit -a) Please try increasing that limit. Note that changing that value at command line might not help. You need...
could you check number of file descriptors that your backend keeps open ? - use ```select pg_backend_pid();``` to get backend's process id - keep it open, issue bunch of cstore...