Issue
为指定表设置自增键的起始值
- 000
3.0版本的自增键功能，增加为指定表设置自增键的起始值，这样就可以覆盖如下的场景：starrocks的表的历史数据从mysql初始化而来，对应表有个字段为自增键，初始化时，该自增键同时同步过来，后续增量数据进入starrocks时，从指定位置开始自增，这样可以避免新增的自增键值与初始化来的值重复的问题。
- 000
请问什么时候有计划增加对已经存在的表修改comment的功能，类似mysql：ALTER TABLE 表名称 COMMENT '***';
- 000
Problem:
Two problem which limit the download/upload speed:
If we use new authentication framework for S3, the client max connection is 25 by default and is not configurable.
backup/restore's download/upload task is limited that be can handle at most 3 task in a single backup/restore task.
Solutio...
- 000
Steps to reproduce the behavior (Required)
CREATE TABLE site_access (
event_day date NOT NULL COMMENT "",
site_id int(11) NULL DEFAULT "10" COMMENT "",
city_code varchar(100) NULL COMMENT "",
user_name varchar(32) NULL DEFAULT "" COMMENT "",
pv bigint(20) NULL DEFAULT "0" COMMENT ""
) ENGINE=OLAP...
- 000
After the materialized view is created, the FE reports an error when the data is synchronized regularly the next day, and then restarts,
Steps to reproduce the behavior (Required)
2023-06-05 14:59:10,553 WARN (stateChangeExecutor|68) [LakeTablet.getBackendIds():90] Failed to get backends by shard....
- 000
Real behavior (Required)
libtool: link: /usr/bin/../bin/gcc -Wall -W -o dbconverter-2 dbconverter-2.o ../sasldb/.libs/libsasldb.a ../lib/.libs/libsasl2.a -ldl -lcrypto -lcrypt -lresolv
libtool: link: /usr/bin/../bin/gcc -Wall -W -o pluginviewer pluginviewer.o ../lib/.libs/libsasl2.a -ldl -lcrypto...
- 000
DynamicChunkBufferLimiter will alloc memory in pin method and may throw std::bad_alloc exception.
this method is invoked in ChunkSource::buffer_next_batch_chunks_blocking, if it throws std::bad_alloc exception ,BE will crash.
crash stack like this:
*** Aborted at 1685943281 (unix time) try "date...
- 000
if there is a memory allocation error in ChunkHelper::new_chunk_pooled, it will throw a std::bad_alloc exception, we should handle it.
otherwise, Be will crash, here is a stack as example
*** SIGABRT (@0x3e800007d3c) received by PID 32060 (TID 0x7fe53d8a2700) from PID 32060; stack trace: ***
@...
- 000
I tried to inject memory allocation error during query and found an crash issue.
Steps to reproduce the behavior (Required)
Expected behavior (Required)
Real behavior (Required)
StarRocks version (Required)
You can get the StarRocks version by executing SQL select current_version()
main e0a3851
- 000
Enhancement
mv: a left outer join b on a.c1 = b.c2
query: a inner join b on a.c1 = b.c2
query should be rewritten as:
select * from mv 1 where b.c2 is not null
or the compensation predicate is null-eliminated for right table